From djm at mindrot.org Thu Mar 1 07:31:23 2012 From: djm at mindrot.org (Damien Miller) Date: Thu, 1 Mar 2012 07:31:23 +1100 (EST) Subject: FIPS fix for signature verification in ssh-rsa.c In-Reply-To: <20120223182540.GB6046@cisco.com> References: <20120223182540.GB6046@cisco.com> Message-ID: On Thu, 23 Feb 2012, Keith Kaple wrote: > code version referenced: openssh-5.9p1 > > Hi all, > > When building openssh with openssl (specifically versions newer > than openssl 0.9.8q), there is an issue if FIPS mode is active for > openssl. In ssh-rsa.c on line 243 RSA_public_decrypt is called, which > is disallowed now in openssl (if in FIPS mode). The library requires > appliactions to use the EVP API if running in FIPS mode so it can > disallow certain cipher suites and hash algorithms that are not > considered FIPS compliant. The user experience is that the scp/ssh > client fails because RSA_public_decrypt just returns null if FIPS mode > is active in openssl > 0.9.8q. > > I have a fix, essentially just check for FIPS mode in ssh-rsa.c and > appropriately call a new function which uses the EVP API of openssl. > I'll be putting this fix in the fedora based rpm we're using in our > appliance based product, but also wanted to offer the fix here so it > can propogate to future linux distro releases. > > This is my first source modification of openssh so I'm not sure what I > need to do to get approval/acceptance of the change or how to commit > it, please let me know what the process is... The usual way is to post the patch to https://bugzilla.mindrot.org in a new bug. We'll (eventually) get to looking at it. -d From tanguy+openssh at ortolo.eu Mon Mar 5 20:21:52 2012 From: tanguy+openssh at ortolo.eu (Tanguy Ortolo) Date: Mon, 5 Mar 2012 10:21:52 +0100 Subject: Unix socket forwarding Message-ID: <20120305092152.GA10207@ortolo.eu> Hello, There is one option I would love to see with OpenSSH: generic Unix socket forwarding. Something like that: $ ssh -L /tmp/pulse-2L9K88eMlGn7/native:/tmp/pulse-42 remotehost (and the same with -R) The code should already be here, since OpenSSH already implements two specific cases of Unix socket forwarding: X11 and SSH agent forwarding. Having an option for generic Unix socket forwarding would allow for any number of other cases, including audio server, PGP agent, keyring server or whatever. Regards, -- Tanguy Ortolo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From dkg at fifthhorseman.net Tue Mar 6 04:43:11 2012 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 05 Mar 2012 12:43:11 -0500 Subject: Unix socket forwarding In-Reply-To: <20120305092152.GA10207@ortolo.eu> References: <20120305092152.GA10207@ortolo.eu> Message-ID: <4F54FB2F.5060300@fifthhorseman.net> Hi Tanguy-- On 03/05/2012 04:21 AM, Tanguy Ortolo wrote: > There is one option I would love to see with OpenSSH: generic Unix > socket forwarding. I agree this would be useful. It's probably best to follow up on this request at its upstream bugzilla entry [0]. If someone interested could make a revision of the patch at [1] that applies (and builds and tests) cleanly against the current version of OpenSSH, that would be great. --dkg [0] https://bugzilla.mindrot.org/show_bug.cgi?id=1256 [1] http://www.25thandclement.com/~william/projects/streamlocal.html From william at 25thandClement.com Tue Mar 6 06:44:05 2012 From: william at 25thandClement.com (William Ahern) Date: Mon, 5 Mar 2012 11:44:05 -0800 Subject: Unix socket forwarding In-Reply-To: <4F54FB2F.5060300@fifthhorseman.net> References: <20120305092152.GA10207@ortolo.eu> <4F54FB2F.5060300@fifthhorseman.net> Message-ID: <20120305194405.GA702@wilbur.25thandClement.com> On Mon, Mar 05, 2012 at 12:43:11PM -0500, Daniel Kahn Gillmor wrote: > Hi Tanguy-- > > On 03/05/2012 04:21 AM, Tanguy Ortolo wrote: > > There is one option I would love to see with OpenSSH: generic Unix > > socket forwarding. > > I agree this would be useful. > > It's probably best to follow up on this request at its upstream bugzilla > entry [0]. > > If someone interested could make a revision of the patch at [1] that > applies (and builds and tests) cleanly against the current version of > OpenSSH, that would be great. > > --dkg > > [0] https://bugzilla.mindrot.org/show_bug.cgi?id=1256 > [1] http://www.25thandclement.com/~william/projects/streamlocal.html If there's real interest by the team to accept the feature, I'd be happy to update my patch and workout any integration issues and misgivings. But for years there's been nothing but stone cold silence concerning this feature. From dkg at fifthhorseman.net Tue Mar 6 07:08:16 2012 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 05 Mar 2012 15:08:16 -0500 Subject: Unix socket forwarding In-Reply-To: <20120305194405.GA702@wilbur.25thandClement.com> References: <20120305092152.GA10207@ortolo.eu> <4F54FB2F.5060300@fifthhorseman.net> <20120305194405.GA702@wilbur.25thandClement.com> Message-ID: <4F551D30.1030304@fifthhorseman.net> On 03/05/2012 02:44 PM, William Ahern wrote: > If there's real interest by the team to accept the feature, I'd be happy to > update my patch and workout any integration issues and misgivings. But for > years there's been nothing but stone cold silence concerning this feature. While i understand your frustration, i think the way to demonstrate that a feature is actively desired is to keep the patch up-to-date, and try to encourage people to try it out and give feedback. I'm not on the OpenSSH dev team, so i can't guarantee their responses, but certainly having an active group of people using such a feature (and having a well-written, up-to-date patch that simplifies things and minimizes configuration complexity) would be a good thing. Some devil-is-in-the-details questions: 0) Have you thought about how you'd expect the patch to interact with the "no-port-forwarding" argument in authorized_keys files (see sshd(8))? Do you want to introduce a new authorized_keys argument to deal strictly with unix-domain sockets? 1) What about AllowTcpForwarding in sshd_config(5)? Will this patch introduce a new configuration option for sshd_config? 2) Are all forwarded unix-domain sockets going to be of type SOCK_STREAM, or is it possible to forward a SOCK_DGRAM (or SOCK_SEQPACKET or SOCK_RAW) socket? 3) Should ssh be able to connect a local unix domain socket to a remote TCP port? or vice versa? If so, how does that decision affect the configuration option decisions you've made in (0) and (1)? 4) Given that the process is currently doable (albeit with some command-line complexity) without implementing it directly in ssh (e,g, http://www.debian-administration.org/users/dkg/weblog/68), are the additional configuration complexities introduced into ssh worth the gain for those of us who want to use the feature? I don't mean these questions as discouragement; on the contrary, i think having a clear and well-justified answer to these questions should make a stronger argument for adoption of a patch that implements the feature. --dkg From william at 25thandClement.com Tue Mar 6 08:11:37 2012 From: william at 25thandClement.com (William Ahern) Date: Mon, 5 Mar 2012 13:11:37 -0800 Subject: Unix socket forwarding In-Reply-To: <4F551D30.1030304@fifthhorseman.net> References: <20120305092152.GA10207@ortolo.eu> <4F54FB2F.5060300@fifthhorseman.net> <20120305194405.GA702@wilbur.25thandClement.com> <4F551D30.1030304@fifthhorseman.net> Message-ID: <20120305211137.GA32652@wilbur.25thandClement.com> On Mon, Mar 05, 2012 at 03:08:16PM -0500, Daniel Kahn Gillmor wrote: > On 03/05/2012 02:44 PM, William Ahern wrote: > > > If there's real interest by the team to accept the feature, I'd be happy to > > update my patch and workout any integration issues and misgivings. But for > > years there's been nothing but stone cold silence concerning this feature. > > While i understand your frustration, i think the way to demonstrate that > a feature is actively desired is to keep the patch up-to-date, and try > to encourage people to try it out and give feedback. I'm not frustrated. The patch has been used on tens of thousands of machines across the globe for going on half a decade now without a single known issue. It's always nicer, of course, to have a feature committed upstream, but what can you do? It's always more frustrating as a maintainer of a large project because everybody and their cousin submits patches. You're often reticent to accept even the good patches because it just adds to the overall cognitive burden. I get that. It just seems to me like the developers just aren't that interested in the feature, period, and for whatever reasons they've silently kept that opinion to themselves. That's a perfectly reasonable judgment call. Whenever the subject comes up I renew my offer to revamp, but unless and until there's some interest from the core developers I'm not going to spend time on it. It's very time consuming integrating a large patch into an upstream project; impossible, in fact, without feedback from the developers. > I'm not on the OpenSSH dev team, so i can't guarantee their responses, > but certainly having an active group of people using such a feature (and > having a well-written, up-to-date patch that simplifies things and > minimizes configuration complexity) would be a good thing. > > Some devil-is-in-the-details questions: I'm intimately aware of the details. Outside of the core developers and a small cadre of hackers I probably became more familiar with the OpenSSH codebase than anyone else. It's an intrusive patch and required additions to the underlying protocol, fixes to options parsing code, and a refactoring of several data structures and related code. The fact that X11 forwarding already exists--as pointed out by the OP--turns out to not matter one iota because of the SSH protocol spec and the architecture of OpenSSH in particular. As for having an active group, that's hard to quantify. How would you define the active group for port forwarding? You really can't. It's used by a large, disparate group of people for all manner of random purposes. Domain socket forwarding may in fact be a poor feature for inclusion given the alternatives. The fact that everybody but the core developers think it's a good idea, and yet I've been the only one to cook up a patch, tends to suggest a lack of substantive demand. Or perhaps my patch sufficed for the those who really needed the feature, which lessed pressure for inclusion or addition upstream. Who knows? From dkg at fifthhorseman.net Tue Mar 6 08:40:22 2012 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 05 Mar 2012 16:40:22 -0500 Subject: Unix socket forwarding In-Reply-To: <20120305211137.GA32652@wilbur.25thandClement.com> References: <20120305092152.GA10207@ortolo.eu> <4F54FB2F.5060300@fifthhorseman.net> <20120305194405.GA702@wilbur.25thandClement.com> <4F551D30.1030304@fifthhorseman.net> <20120305211137.GA32652@wilbur.25thandClement.com> Message-ID: <4F5532C6.1060102@fifthhorseman.net> On 03/05/2012 04:11 PM, William Ahern wrote: > I'm intimately aware of the details. Outside of the core developers and a > small cadre of hackers I probably became more familiar with the OpenSSH > codebase than anyone else. It's an intrusive patch and required additions to > the underlying protocol, fixes to options parsing code, and a refactoring of > several data structures and related code. The fact that X11 forwarding > already exists--as pointed out by the OP--turns out to not matter one iota > because of the SSH protocol spec and the architecture of OpenSSH in > particular. yikes! I can see why something this hairy would make upstream shy. Are the extensions to the protocol documented someplace? I couldn't find them at http://www.25thandclement.com/~william/projects/streamlocal.html > The fact that everybody but the core developers think it's a > good idea, and yet I've been the only one to cook up a patch, tends to > suggest a lack of substantive demand. Or perhaps my patch sufficed for the > those who really needed the feature, which lessed pressure for inclusion or > addition upstream. Who knows? It's also possible that the feasibility of hooking ssh into a common utility like socat satisfies the majority of users who want the functionality but can't vet such a complex/complicated patch. --dkg From william at 25thandClement.com Tue Mar 6 10:36:10 2012 From: william at 25thandClement.com (William Ahern) Date: Mon, 5 Mar 2012 15:36:10 -0800 Subject: Unix socket forwarding In-Reply-To: <4F5532C6.1060102@fifthhorseman.net> References: <20120305092152.GA10207@ortolo.eu> <4F54FB2F.5060300@fifthhorseman.net> <20120305194405.GA702@wilbur.25thandClement.com> <4F551D30.1030304@fifthhorseman.net> <20120305211137.GA32652@wilbur.25thandClement.com> <4F5532C6.1060102@fifthhorseman.net> Message-ID: <20120305233610.GA26345@wilbur.25thandClement.com> On Mon, Mar 05, 2012 at 04:40:22PM -0500, Daniel Kahn Gillmor wrote: > On 03/05/2012 04:11 PM, William Ahern wrote: > > I'm intimately aware of the details. Outside of the core developers and a > > small cadre of hackers I probably became more familiar with the OpenSSH > > codebase than anyone else. It's an intrusive patch and required additions to > > the underlying protocol, fixes to options parsing code, and a refactoring of > > several data structures and related code. The fact that X11 forwarding > > already exists--as pointed out by the OP--turns out to not matter one iota > > because of the SSH protocol spec and the architecture of OpenSSH in > > particular. > > yikes! I can see why something this hairy would make upstream shy. Are > the extensions to the protocol documented someplace? I couldn't find > them at http://www.25thandclement.com/~william/projects/streamlocal.html > http://lists.mindrot.org/pipermail/openssh-unix-dev/2006-April/024201.html From peter at stuge.se Tue Mar 6 11:04:41 2012 From: peter at stuge.se (Peter Stuge) Date: Tue, 6 Mar 2012 01:04:41 +0100 Subject: Unix socket forwarding In-Reply-To: <20120305211137.GA32652@wilbur.25thandClement.com> References: <20120305092152.GA10207@ortolo.eu> <4F54FB2F.5060300@fifthhorseman.net> <20120305194405.GA702@wilbur.25thandClement.com> <4F551D30.1030304@fifthhorseman.net> <20120305211137.GA32652@wilbur.25thandClement.com> Message-ID: <20120306000441.4336.qmail@stuge.se> William Ahern wrote: > I'm intimately aware of the details. Outside of the core developers > and a small cadre of hackers I probably became more familiar with > the OpenSSH codebase than anyone else. It's an intrusive patch and > required additions to the underlying protocol, fixes to options > parsing code, and a refactoring of several data structures and > related code. Each of these properties is enough motivation to reject the patch. > The fact that X11 forwarding already exists--as pointed out by the > OP--turns out to not matter one iota because of the SSH protocol > spec and the architecture of OpenSSH in particular. The spec is the bigger problem. Nobody likes private extensions.. > The fact that everybody but the core developers think it's a good idea, Don't put words in my mouth please. I think it's a terrible idea because of all the required changes. > and yet I've been the only one to cook up a patch, tends to > suggest a lack of substantive demand. I think this is spot on. If I would need to do this I would indeed use socat, possibly as an ssh subsystem. //Peter From william at 25thandClement.com Tue Mar 6 12:09:56 2012 From: william at 25thandClement.com (William Ahern) Date: Mon, 5 Mar 2012 17:09:56 -0800 Subject: Unix socket forwarding In-Reply-To: <20120306000441.4336.qmail@stuge.se> References: <20120305092152.GA10207@ortolo.eu> <4F54FB2F.5060300@fifthhorseman.net> <20120305194405.GA702@wilbur.25thandClement.com> <4F551D30.1030304@fifthhorseman.net> <20120305211137.GA32652@wilbur.25thandClement.com> <20120306000441.4336.qmail@stuge.se> Message-ID: <20120306010956.GA21668@wilbur.25thandClement.com> On Tue, Mar 06, 2012 at 01:04:41AM +0100, Peter Stuge wrote: > William Ahern wrote: > > I'm intimately aware of the details. Outside of the core developers > > and a small cadre of hackers I probably became more familiar with > > the OpenSSH codebase than anyone else. It's an intrusive patch and > > required additions to the underlying protocol, fixes to options > > parsing code, and a refactoring of several data structures and > > related code. > > Each of these properties is enough motivation to reject the patch. > > > > The fact that X11 forwarding already exists--as pointed out by the > > OP--turns out to not matter one iota because of the SSH protocol > > spec and the architecture of OpenSSH in particular. > > The spec is the bigger problem. Nobody likes private extensions.. > > > > The fact that everybody but the core developers think it's a good idea, > > Don't put words in my mouth please. Please excuse my hyperbole. > I think it's a terrible idea because of all the required changes. All things being equal, I'd agree with you. But all things aren't equal. Forwarding support is more central to the function of SSH than any old feature. It's an open-ended capability that increases the utility of ssh manyfold. And a ton of junk has gone into OpenSSH over the years, and continues to be added. And many of my changes actually improved the quality of the code base, IMNSHO. The patch reduced obsfuscation of socket handling in many cases, and would have eased some of the changes in the intervening years. Adding domain socket support is a sane generalization of the existing system. Certainly saner than, say, adding tun/tap support ;) I mean, how much more useful on a day-to-day basis is it to be able to easily forward a MySQL or PostgreSQL domain socket (especially when, for security reasons--e.g. socket credential authentication or minimal dependency on a firewall to protect your data--you disable TCP access) than it is to use SSH for an esoteric and ad hoc (albeit, sometimes very cool and useful) VPN? socat is _not_ convenient. It's not even portable. There's socat, nc, netcat, and perhaps more often than not, nothing. I think the _idea_ of adding domain socket support--even given the hairiness of OpenSSH's code base--is quite defensible. From dan at doxpara.com Tue Mar 6 12:21:40 2012 From: dan at doxpara.com (Dan Kaminsky) Date: Mon, 5 Mar 2012 20:21:40 -0500 Subject: Unix socket forwarding In-Reply-To: <20120306010956.GA21668@wilbur.25thandClement.com> References: <20120305092152.GA10207@ortolo.eu> <4F54FB2F.5060300@fifthhorseman.net> <20120305194405.GA702@wilbur.25thandClement.com> <4F551D30.1030304@fifthhorseman.net> <20120305211137.GA32652@wilbur.25thandClement.com> <20120306000441.4336.qmail@stuge.se> <20120306010956.GA21668@wilbur.25thandClement.com> Message-ID: > > > I think the _idea_ of adding domain socket support--even given the > hairiness > of OpenSSH's code base--is quite defensible. > > For what it's worth, I'm now inclined to agree (specifically, the mysql/postgresql domain sockets push me well over the edge). From peter at stuge.se Tue Mar 6 13:01:54 2012 From: peter at stuge.se (Peter Stuge) Date: Tue, 6 Mar 2012 03:01:54 +0100 Subject: Unix socket forwarding In-Reply-To: <20120306010956.GA21668@wilbur.25thandClement.com> References: <20120305092152.GA10207@ortolo.eu> <4F54FB2F.5060300@fifthhorseman.net> <20120305194405.GA702@wilbur.25thandClement.com> <4F551D30.1030304@fifthhorseman.net> <20120305211137.GA32652@wilbur.25thandClement.com> <20120306000441.4336.qmail@stuge.se> <20120306010956.GA21668@wilbur.25thandClement.com> Message-ID: <20120306020154.13319.qmail@stuge.se> William Ahern wrote: > > I think it's a terrible idea because of all the required changes. > > All things being equal, I'd agree with you. But all things aren't equal. > Forwarding support is more central to the function of SSH than any old > feature. It's an open-ended capability that increases the utility of ssh > manyfold. Mh. TCP isn't rocket science. I agree that it's handy sometimes, but generally when you would want to use it, it's for users who need so much handholding that you might as well write them a special purpose SSH client instead. > many of my changes actually improved the quality of the code base, > IMNSHO. The patch reduced obsfuscation of socket handling in many > cases, and would have eased some of the changes in the intervening > years. So maybe a good way to get the feature included is to submit these preparatory improvements one by one, as opposed to everything in one unhandlable monolith change. > Adding domain socket support is a sane generalization of the existing > system. Certainly saner than, say, adding tun/tap support ;) Just because tun is foreign to you doesn't mean that it is so for others. I used (programmed) tun for the first time some 15 years ago. > I mean, how much more useful on a day-to-day basis is it to be able to > easily forward a MySQL or PostgreSQL domain socket (especially when, for > security reasons--e.g. socket credential authentication or minimal > dependency on a firewall to protect your data--you disable TCP access) Sure, peercred authentication is a neat trick and AF_UNIX forwarding could simplify it remotely, but I still think that if you have this need then adding socat to the system and configuring a subsystem is really quite trivial for any systems administrator worth their title. > than it is to use SSH for an esoteric and ad hoc (albeit, sometimes > very cool and useful) VPN? I don't know if I agree about esoteric and ad-hoc. tun is not new to me, and any VPN can be connected or disconnected. > socat is _not_ convenient. It's not even portable. There's socat, > nc, netcat, and perhaps more often than not, nothing. I disagree strongly. If AF_UNIX forwarding was in SSH protocol then it would be easy to argue for supporting it. But since SSH is specifically not only for UNIX and -like systems I'm happy that it isn't in the protocol. socat is the needed abstraction and is portable across "AIX, BSD, HP-UX, Linux, Solaris e.a. (UNIX)" according to http://www.dest-unreach.org/socat/ > I think the _idea_ of adding domain socket support--even given the > hairiness of OpenSSH's code base--is quite defensible. Like tun channels I think AF_UNIX channels is a neat hack. But there is obviously zero chance of inclusion unless the final patch to add the feature is clean. The obvious way is to break it down into a set of patches with clear one-by-one improvements. I guess you know this already. //Peter From mr.dash.four at googlemail.com Tue Mar 6 15:13:36 2012 From: mr.dash.four at googlemail.com (Mr Dash Four) Date: Tue, 06 Mar 2012 04:13:36 +0000 Subject: openssh static build - mission impossible? Message-ID: <4F558EF0.3000308@googlemail.com> I am trying to build a static version of ssh, sshd and sftp, but after banging my head against the wall for the best part of the last 3 days I am about to give up... Since I plan to use this on an embedded device (building dropbear is *NOT* an option!), I've excluded as many openssh configure options as I can but, ultimately, failed. This is my setup: export LDFLAGS=' -pie -z relro -z now' export CFLAGS='-O2 -g -march=armv6j -mtune=arm1136jf-s -mthumb-interwork -mno-thumb -Os -fpic' export CXXFLAGS='-O2 -g -march=armv6j -mtune=arm1136jf-s -mthumb-interwork -mno-thumb' export FFLAGS='-O2 -g -march=armv6j -mtune=arm1136jf-s -mthumb-interwork -mno-thumb' ./configure \ --host=armv6l-redhat-linux-gnueabi \ --build=armv7l-unknown-linux-gnueabi \ --program-prefix= --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info --sysconfdir=/etc/ssh --libexecdir=/usr/libexec/openssh --datadir=/usr/share/openssh \ --without-tcp-wrappers \ --with-default-path=/usr/local/bin:/bin:/usr/bin \ --with-superuser-path=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin \ --with-privsep-path=/var/empty/sshd \ --disable-strip \ --without-zlib-version-check \ --with-ssl-engine \ --with-authorized-keys-command \ --disable-lastlog \ --disable-utmp \ --disable-utmpx \ --disable-wtmp \ --disable-wtmpx \ --without-shadow \ --without-nss \ --without-smartcard \ --without-ldap \ --without-pam \ --without-selinux \ --without-audit \ --without-kerberos5 \ --without-libedit \ --with-ldflags=-static This passes through, no problem (I have a separate, and ultimately head-wrecking problem with using "--with-tcp-wrappers", but that is the least of my problems right now) and I get the following summary: op OpenSSH has been configured with the following options: User binaries: /usr/bin System binaries: /usr/sbin Configuration files: /etc/ssh Askpass program: /usr/libexec/openssh/ssh-askpass Manual pages: /usr/share/man/manX PID file: /var/run Privilege separation chroot path: /var/empty/sshd sshd default user PATH: /usr/local/bin:/bin:/usr/bin sshd superuser user PATH: /usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin Manpage format: doc PAM support: no OSF SIA support: no KerberosV support: no SELinux support: no Smartcard support: S/KEY support: no TCP Wrappers support: no MD5 password support: no libedit support: no Solaris process contract support: no IP address in $DISPLAY hack: no Translate v4 in v6 hack: yes BSD Auth support: no Random number source: OpenSSL internal ONLY Host: armv6l-redhat-linux-gnueabi Compiler: gcc Compiler flags: -O2 -g -march=armv6j -mtune=arm1136jf-s -mthumb-interwork -mno-thumb -Os -fpic -Wall -Wpointer-arith -Wuninitialized -Wsign-compare -Wno-pointer-sign -Wformat-security -fno-strict-aliasing -fno-builtin-memset -fstack-protector-all Preprocessor flags: Linker flags: -pie -z relro -z now -fstack-protector-all -static Libraries: -lcrypto -ldl -lutil -lz -lresolv When I then execute make, I get this after a while: /usr/lib/gcc/armv5tel-redhat-linux-gnueabi/4.6.1/../../../libcrypto.a(fips.o): In function `FIPSCHECK_verify': (.text+0x20): warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking groupaccess.o: In function `ga_init': /builddir/build/BUILD/openssh-5.6p1/groupaccess.c:66: warning: Using 'getgrouplist' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking session.o: In function `do_setusercontext': /builddir/build/BUILD/openssh-5.6p1/session.c:1509: warning: Using 'initgroups' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking groupaccess.o: In function `ga_init': /builddir/build/BUILD/openssh-5.6p1/groupaccess.c:69: warning: Using 'getgrgid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking sshpty.o: In function `pty_setowner': /builddir/build/BUILD/openssh-5.6p1/sshpty.c:211: warning: Using 'getgrnam' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking session.o: In function `do_setusercontext': /builddir/build/BUILD/openssh-5.6p1/session.c:1513: warning: Using 'endgrent' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking sshd.o: In function `main': /builddir/build/BUILD/openssh-5.6p1/sshd.c:1545: warning: Using 'getpwnam' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking loginrec.o: In function `login_get_lastlog': /builddir/build/BUILD/openssh-5.6p1/loginrec.c:312: warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking sshd.o: In function `main': /builddir/build/BUILD/openssh-5.6p1/sshd.c:1555: warning: Using 'endpwent' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking servconf.o: In function `add_one_listen_addr': /builddir/build/BUILD/openssh-5.6p1/servconf.c:515: warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking ./libssh.a(canohost.o): In function `check_ip_options': /builddir/build/BUILD/openssh-5.6p1/canohost.c:168: warning: Using 'getprotobyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking openbsd-compat//libopenbsd-compat.a(xcrypt.o): In function `xcrypt': /builddir/build/BUILD/openssh-5.6p1/openbsd-compat/xcrypt.c:78: undefined reference to `crypt' /usr/bin/ld: /usr/lib/gcc/armv5tel-redhat-linux-gnueabi/4.6.1/../../../libc.a(inet_ntoa.o)(.text+0x54): R_ARM_TLS_LE32 relocation not permitted in shared object /usr/bin/ld: /usr/lib/gcc/armv5tel-redhat-linux-gnueabi/4.6.1/../../../libc.a(dl-tsd.o)(.text+0x14): R_ARM_TLS_LE32 relocation not permitted in shared object collect2: ld returned 1 exit status So, I figured, I need to include -lcrypt in the mix, but then I get this: gcc -o sshd sshd.o auth-rhosts.o auth-passwd.o auth-rsa.o auth-rh-rsa.o sshpty.o sshlogin.o servconf.o serverloop.o auth.o auth1.o auth2.o auth-options.o session.o auth-chall.o auth2-chall.o groupaccess.o auth-skey.o auth-bsdauth.o auth2-hostbased.o auth2-kbdint.o auth2-none.o auth2-passwd.o auth2-pubkey.o auth2-jpake.o monitor_mm.o monitor.o monitor_wrap.o kexdhs.o kexgexs.o auth-krb5.o auth2-gss.o gss-serv.o gss-serv-krb5.o loginrec.o auth-pam.o auth-shadow.o auth-sia.o md5crypt.o audit.o audit-bsm.o platform.o sftp-server.o sftp-common.o roaming_common.o roaming_serv.o -L. -Lopenbsd-compat/ -pie -z relro -z now -lnsl -lpcre -lcdb -fstack-protector-all -static -static-libgcc -lssh -lopenbsd-compat -lcrypto -lcrypt -ldl -lutil -lz -lresolv /usr/lib/gcc/armv5tel-redhat-linux-gnueabi/4.6.1/../../../libcrypto.a(fips.o): In function `FIPSCHECK_verify': (.text+0x20): warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking groupaccess.o: In function `ga_init': /builddir/build/BUILD/openssh-5.6p1/groupaccess.c:66: warning: Using 'getgrouplist' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking session.o: In function `do_setusercontext': /builddir/build/BUILD/openssh-5.6p1/session.c:1509: warning: Using 'initgroups' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking groupaccess.o: In function `ga_init': /builddir/build/BUILD/openssh-5.6p1/groupaccess.c:69: warning: Using 'getgrgid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking sshpty.o: In function `pty_setowner': /builddir/build/BUILD/openssh-5.6p1/sshpty.c:211: warning: Using 'getgrnam' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking session.o: In function `do_setusercontext': /builddir/build/BUILD/openssh-5.6p1/session.c:1513: warning: Using 'endgrent' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking sshd.o: In function `main': /builddir/build/BUILD/openssh-5.6p1/sshd.c:1545: warning: Using 'getpwnam' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking loginrec.o: In function `login_get_lastlog': /builddir/build/BUILD/openssh-5.6p1/loginrec.c:312: warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking sshd.o: In function `main': /builddir/build/BUILD/openssh-5.6p1/sshd.c:1555: warning: Using 'endpwent' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking servconf.o: In function `add_one_listen_addr': /builddir/build/BUILD/openssh-5.6p1/servconf.c:515: warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking ./libssh.a(canohost.o): In function `check_ip_options': /builddir/build/BUILD/openssh-5.6p1/canohost.c:168: warning: Using 'getprotobyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/lib/gcc/armv5tel-redhat-linux-gnueabi/4.6.1/../../../libcrypt.a(md5-crypt.o): In function `__md5_crypt_r': (.text+0xb4): undefined reference to `NSSLOW_Init' /usr/lib/gcc/armv5tel-redhat-linux-gnueabi/4.6.1/../../../libcrypt.a(md5-crypt.o): In function `__md5_crypt_r': [... Ad nauseum!] /usr/lib/gcc/armv5tel-redhat-linux-gnueabi/4.6.1/../../../libcrypt.a(sha512-crypt.o): In function `__sha512_crypt_r': (.text+0x1088): undefined reference to `NSSLOWHASH_Update' /usr/lib/gcc/armv5tel-redhat-linux-gnueabi/4.6.1/../../../libcrypt.a(sha512-crypt.o): In function `__sha512_crypt_r': (.text+0x10d0): undefined reference to `NSSLOWHASH_End' /usr/lib/gcc/armv5tel-redhat-linux-gnueabi/4.6.1/../../../libcrypt.a(sha512-crypt.o): In function `__sha512_crypt_r': (.text+0x10d8): undefined reference to `NSSLOWHASH_Destroy' /usr/bin/ld: /usr/lib/gcc/armv5tel-redhat-linux-gnueabi/4.6.1/../../../libc.a(inet_ntoa.o)(.text+0x54): R_ARM_TLS_LE32 relocation not permitted in shared object /usr/bin/ld: /usr/lib/gcc/armv5tel-redhat-linux-gnueabi/4.6.1/../../../libc.a(dl-tsd.o)(.text+0x14): R_ARM_TLS_LE32 relocation not permitted in shared object collect2: ld returned 1 exit status >From what I gather, all these NSS* references are from the nss-* packages/libraries, and to my knowledge, there isn't a static version of it. Any pointers as how to get out of this mess would be greately appreciated, thanks! From mr.dash.four at googlemail.com Tue Mar 6 15:32:40 2012 From: mr.dash.four at googlemail.com (Mr Dash Four) Date: Tue, 06 Mar 2012 04:32:40 +0000 Subject: openssh static build - mission impossible? In-Reply-To: <20120306042327.GA2496@mercury.spuddy.org> References: <4F558EF0.3000308@googlemail.com> <20120306042327.GA2496@mercury.spuddy.org> Message-ID: <4F559368.1030203@googlemail.com> Stephen Harris wrote: > I'm not an ssh developer, but... > >> /builddir/build/BUILD/openssh-5.6p1/groupaccess.c:66: warning: Using 'getgrouplist' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking > > The problem, here, is that glibc uses nsswitch.conf and nss libraries > can be dynamically loaded (nss_ldap, nss_files, nss_nis, etc etc). > getgrouplist() is a function that inherently uses the name service > resolving routines in glibc. It is highly unlikely that I will ever need or use the name resolution service on the host device, so I am not worried by that aspect (I had this warning while building other statically-linked programs - openvpn comes to mind - that work just fine with no "side effects"). I also explicitly deactivated nss (hence "--without-nss"). > If you're building your own embedded system then you should use a > different libc implementation (uclibc, perhaps?) that doesn't _require_ > dynamic linking. That is not an option for me at all - it is either statically-linked openssh or nada! From peter at stuge.se Tue Mar 6 16:28:25 2012 From: peter at stuge.se (Peter Stuge) Date: Tue, 6 Mar 2012 06:28:25 +0100 Subject: openssh static build - mission impossible? In-Reply-To: <4F558EF0.3000308@googlemail.com> References: <4F558EF0.3000308@googlemail.com> Message-ID: <20120306052826.30761.qmail@stuge.se> Mr Dash Four wrote: > ./configure \ > --host=armv6l-redhat-linux-gnueabi \ > --build=armv7l-unknown-linux-gnueabi \ Why? For which tuple are you building, and with which tuple are you building? > When I then execute make, I get this after a while: You should not have cut away the command doing the linking. I.e. *never* remove output when you are asking for help, because chances are quite significant that you are removing the single key piece of information required in order to determine the actual error. > gcc -o sshd sshd.o auth-rhosts.o auth-passwd.o auth-rsa.o auth-rh-rsa.o sshpty.o sshlogin.o servconf.o serverloop.o auth.o auth1.o auth2.o auth-options.o session.o auth-chall.o auth2-chall.o groupaccess.o auth-skey.o auth-bsdauth.o auth2-hostbased.o auth2-kbdint.o auth2-none.o auth2-passwd.o auth2-pubkey.o auth2-jpake.o monitor_mm.o monitor.o monitor_wrap.o kexdhs.o kexgexs.o auth-krb5.o auth2-gss.o gss-serv.o gss-serv-krb5.o loginrec.o auth-pam.o auth-shadow.o auth-sia.o md5crypt.o audit.o audit-bsm.o platform.o sftp-server.o sftp-common.o roaming_common.o roaming_serv.o -L. -Lopenbsd-compat/ -pie -z relro -z now -lnsl -lpcre -lcdb -fstack-protector-all -static -static-libgcc -lssh -lopenbsd-compat -lcrypto -lcrypt -ldl -lutil -lz -lresolv Who is running this command? Are you running it manually? You create significant unneccessary confusion by not including complete output from make without making any changes. > /usr/lib/gcc/armv5tel-redhat-linux-gnueabi/4.6.1/../../../libcrypt.a(md5-crypt.o): In function `__md5_crypt_r': (.text+0xb4): undefined reference to `NSSLOW_Init' If you resolve that path you get /usr/lib/libcrypt.a and unless you are building both on and for armv6l-redhat-linux-gnueabi then that is certainly not the file you want to link against. Are you cross-compiling or not? > From what I gather, all these NSS* references are from the nss-* > packages/libraries, and to my knowledge, there isn't a static > version of it. Any pointers as how to get out of this mess would be > greately appreciated, thanks! If you show complete output then it is possible to say if you have done anything wrong. If libcrypt.a for your target indeed requires NSS then I suggest writing a replacement crypt() which you can link OpenSSH against. Possibly there is one included in OpenSSH already, and you just need to configure correctly to have it used. //Peter From mr.dash.four at googlemail.com Tue Mar 6 16:43:10 2012 From: mr.dash.four at googlemail.com (Mr Dash Four) Date: Tue, 06 Mar 2012 05:43:10 +0000 Subject: openssh static build - mission impossible? In-Reply-To: <20120306052826.30761.qmail@stuge.se> References: <4F558EF0.3000308@googlemail.com> <20120306052826.30761.qmail@stuge.se> Message-ID: <4F55A3EE.6080506@googlemail.com> >> ./configure \ >> --host=armv6l-redhat-linux-gnueabi \ >> --build=armv7l-unknown-linux-gnueabi \ > > Why? For which tuple are you building, and with which tuple are you > building? The "build" tuple is set "automatically" by Fedora (wrongly as it turns out, but that is another issue I am not going to bother you with). The host is set up manually by myself in the .spec file I am using. Regardless of the 2nd part of that tuple the end result is the same, so I don't think this is a major issue or the one which causes openssh build to fail. > You should not have cut away the command doing the linking. I.e. > *never* remove output when you are asking for help, because chances > are quite significant that you are removing the single key piece of > information required in order to determine the actual error. It is quite a large output, but I am enclosing it as an attachment so that I don't clutter this post unnecessarily. >> gcc -o sshd sshd.o auth-rhosts.o auth-passwd.o auth-rsa.o auth-rh-rsa.o sshpty.o sshlogin.o servconf.o serverloop.o auth.o auth1.o auth2.o auth-options.o session.o auth-chall.o auth2-chall.o groupaccess.o auth-skey.o auth-bsdauth.o auth2-hostbased.o auth2-kbdint.o auth2-none.o auth2-passwd.o auth2-pubkey.o auth2-jpake.o monitor_mm.o monitor.o monitor_wrap.o kexdhs.o kexgexs.o auth-krb5.o auth2-gss.o gss-serv.o gss-serv-krb5.o loginrec.o auth-pam.o auth-shadow.o auth-sia.o md5crypt.o audit.o audit-bsm.o platform.o sftp-server.o sftp-common.o roaming_common.o roaming_serv.o -L. -Lopenbsd-compat/ -pie -z relro -z now -lnsl -lpcre -lcdb -fstack-protector-all -static -static-libgcc -lssh -lopenbsd-compat -lcrypto -lcrypt -ldl -lutil -lz -lresolv > > Who is running this command? Are you running it manually? No, why do you say that? > You create > significant unneccessary confusion by not including complete output > from make without making any changes. What do you seem to be confused by? >> /usr/lib/gcc/armv5tel-redhat-linux-gnueabi/4.6.1/../../../libcrypt.a(md5-crypt.o): In function `__md5_crypt_r': (.text+0xb4): undefined reference to `NSSLOW_Init' > > If you resolve that path you get /usr/lib/libcrypt.a and unless you > are building both on and for armv6l-redhat-linux-gnueabi then that is > certainly not the file you want to link against. Are you > cross-compiling or not? I am cross-compiling from armv7l to armv6l as evident from the initial configure. The actual library - /usr/lib/libcrypt.a - is compiled and build for armv5tel (Fedora's own latest "stable"). > If you show complete output then it is possible to say if you have > done anything wrong. OK, I get it! > If libcrypt.a for your target indeed requires > NSS then I suggest writing a replacement crypt() which you can link > OpenSSH against. Easier said than done! > Possibly there is one included in OpenSSH already, > and you just need to configure correctly to have it used. How, exactly? -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: openssh_error.txt URL: From peter at stuge.se Tue Mar 6 17:00:04 2012 From: peter at stuge.se (Peter Stuge) Date: Tue, 6 Mar 2012 07:00:04 +0100 Subject: openssh static build - mission impossible? In-Reply-To: <4F55A3EE.6080506@googlemail.com> References: <4F558EF0.3000308@googlemail.com> <20120306052826.30761.qmail@stuge.se> <4F55A3EE.6080506@googlemail.com> Message-ID: <20120306060004.945.qmail@stuge.se> Mr Dash Four wrote: > >> ./configure \ > >> --host=armv6l-redhat-linux-gnueabi \ > >> --build=armv7l-unknown-linux-gnueabi \ > > > > Why? For which tuple are you building, and with which tuple are you > > building? > > The "build" tuple is set "automatically" by Fedora (wrongly as it > turns out, but that is another issue I am not going to bother you > with). The host is set up manually by myself in the .spec file I am > using. I suggest to build the package manually completely without any spec file or further build tools, in order to find how to build correctly. > >> gcc -o sshd sshd.o ... > > > > Who is running this command? Are you running it manually? > > No, why do you say that? I would expect armv6l-redhat-linux-gnueabi-gcc to be run here, not gcc. > > You create > > significant unneccessary confusion by not including complete output > > from make without making any changes. > > What do you seem to be confused by? The incomplete output. Always include complete logs, including the command you typed and the shell prompt you get after the command has finished. > >> /usr/lib/gcc/armv5tel-redhat-linux-gnueabi/4.6.1/../../../libcrypt.a(md5-crypt.o): In function `__md5_crypt_r': (.text+0xb4): undefined reference to `NSSLOW_Init' > > > > If you resolve that path you get /usr/lib/libcrypt.a and unless you > > are building both on and for armv6l-redhat-linux-gnueabi then that is > > certainly not the file you want to link against. Are you > > cross-compiling or not? > > I am cross-compiling from armv7l to armv6l as evident from the > initial configure. The actual library - /usr/lib/libcrypt.a - is > compiled and build for armv5tel (Fedora's own latest "stable"). Except if you are using the armv5tel gcc and libcrypt.a you are not actually targeting armv6l anymore. > > If libcrypt.a for your target indeed requires > > NSS then I suggest writing a replacement crypt() which you can > > link OpenSSH against. > > Easier said than done! I think that would be easy enough. There must be plenty of implementations to choose from. > > Possibly there is one included in OpenSSH already, > > and you just need to configure correctly to have it used. > > How, exactly? That you get to study on your own. I will not learn about it in order to teach you. You can find out easily by studying the OpenSSH code. //Peter From mr.dash.four at googlemail.com Tue Mar 6 17:32:21 2012 From: mr.dash.four at googlemail.com (Mr Dash Four) Date: Tue, 06 Mar 2012 06:32:21 +0000 Subject: openssh static build - mission impossible? In-Reply-To: <20120306060004.945.qmail@stuge.se> References: <4F558EF0.3000308@googlemail.com> <20120306052826.30761.qmail@stuge.se> <4F55A3EE.6080506@googlemail.com> <20120306060004.945.qmail@stuge.se> Message-ID: <4F55AF75.1080202@googlemail.com> > I suggest to build the package manually completely without any spec > file or further build tools, in order to find how to build correctly. I did try with the same result - no difference whatsoever. > I would expect armv6l-redhat-linux-gnueabi-gcc to be run here, not > gcc. Nope! The compiler is quite capable of producing multi-arch binaries. This particular feature is called "multilib", not sure if you've heard about it, but it does exist. >> I am cross-compiling from armv7l to armv6l as evident from the >> initial configure. The actual library - /usr/lib/libcrypt.a - is >> compiled and build for armv5tel (Fedora's own latest "stable"). > > Except if you are using the armv5tel gcc and libcrypt.a you are not > actually targeting armv6l anymore. As I already mentioned above my gcc compiler is multilib-capable - does that ring any bells? > That you get to study on your own. I will not learn about it in order > to teach you. You can find out easily by studying the OpenSSH code. If you are going to act like a condescending prick, unwilling or incapable of offering anything of interest to this topic, then I'd suggest you move along - there's nothing to see here. From alon.barlev at gmail.com Tue Mar 6 18:43:37 2012 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Tue, 6 Mar 2012 09:43:37 +0200 Subject: openssh static build - mission impossible? In-Reply-To: <4F55AF75.1080202@googlemail.com> References: <4F558EF0.3000308@googlemail.com> <20120306052826.30761.qmail@stuge.se> <4F55A3EE.6080506@googlemail.com> <20120306060004.945.qmail@stuge.se> <4F55AF75.1080202@googlemail.com> Message-ID: On Tue, Mar 6, 2012 at 8:32 AM, Mr Dash Four wrote: >> That you get to study on your own. I will not learn about it in order >> to teach you. You can find out easily by studying the OpenSSH code. > If you are going to act like a condescending prick, unwilling or incapable of offering anything of interest to this topic, then I'd suggest you move along - there's nothing to see here. Peter, a similar [abnormal] discussion was at OpenVPN list[1] Alon. [1] http://sourceforge.net/mailarchive/message.php?msg_id=28878458 From peter at stuge.se Tue Mar 6 18:52:48 2012 From: peter at stuge.se (Peter Stuge) Date: Tue, 6 Mar 2012 08:52:48 +0100 Subject: openssh static build - mission impossible? In-Reply-To: <4F55AF75.1080202@googlemail.com> References: <4F558EF0.3000308@googlemail.com> <20120306052826.30761.qmail@stuge.se> <4F55A3EE.6080506@googlemail.com> <20120306060004.945.qmail@stuge.se> <4F55AF75.1080202@googlemail.com> Message-ID: <20120306075248.9797.qmail@stuge.se> Mr Dash Four wrote: > > I would expect armv6l-redhat-linux-gnueabi-gcc to be run here, > > not gcc. > > Nope! The compiler is quite capable of producing multi-arch > binaries. This particular feature is called "multilib", not > sure if you've heard about it, but it does exist. I know multilib, but.. > >> I am cross-compiling from armv7l to armv6l as evident from the > >> initial configure. The actual library - /usr/lib/libcrypt.a - is > >> compiled and build for armv5tel (Fedora's own latest "stable"). > > > > Except if you are using the armv5tel gcc and libcrypt.a you are not > > actually targeting armv6l anymore. > > As I already mentioned above my gcc compiler is multilib-capable - ..multilib or no, the libcrypt.a being used is from /usr/lib and since you say that this means armv7l then I don't think that is a library you want to use on the armv6l target. The compiler used having yet another tuple (armv5tel) doesn't reduce potential problems and question marks. > > That you get to study on your own. I will not learn about it in order > > to teach you. You can find out easily by studying the OpenSSH code. > > If you are going to act like a condescending prick, unwilling or > incapable of offering anything of interest to this topic, then I'd > suggest you move along - there's nothing to see here. I've pointed to multiple issues worth investigating, and I've explained one certain and one further possible high level solution to your problem even if you choose to completely ignore the issues worth investigating. You can't expect anyone to provide you a tailor made solution that you will just deploy. You have to do the work yourself. I'm sorry if that seems condescending. I think it's just common sense. //Peter From hyc at symas.com Tue Mar 6 19:40:27 2012 From: hyc at symas.com (Howard Chu) Date: Tue, 06 Mar 2012 00:40:27 -0800 Subject: openssh static build - mission impossible? In-Reply-To: <20120306060004.945.qmail@stuge.se> References: <4F558EF0.3000308@googlemail.com> <20120306052826.30761.qmail@stuge.se> <4F55A3EE.6080506@googlemail.com> <20120306060004.945.qmail@stuge.se> Message-ID: <4F55CD7B.4030500@symas.com> Peter Stuge wrote: > Mr Dash Four wrote: >> I am cross-compiling from armv7l to armv6l as evident from the >> initial configure. The actual library - /usr/lib/libcrypt.a - is >> compiled and build for armv5tel (Fedora's own latest "stable"). > > Except if you are using the armv5tel gcc and libcrypt.a you are not > actually targeting armv6l anymore. > > >>> If libcrypt.a for your target indeed requires >>> NSS then I suggest writing a replacement crypt() which you can >>> link OpenSSH against. >> >> Easier said than done! > > I think that would be easy enough. There must be plenty of > implementations to choose from. Sounds like he's been bitten by RedHat/Fedora's policy to replace all crypto on the system with MozillaNSS. You could easily dig up an unmodified glibc source to replace this. Also, the suggestion to use uClibc is still a better one. It will make static linking that much easier as well. Another option is to grab Bionic from the Android source tree; either of these is more compact than the stock Fedora monstrosity. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ From sfandino at yahoo.com Tue Mar 6 20:07:05 2012 From: sfandino at yahoo.com (Salvador Fandino) Date: Tue, 06 Mar 2012 10:07:05 +0100 Subject: openssh static build - mission impossible? In-Reply-To: <4F558EF0.3000308@googlemail.com> References: <4F558EF0.3000308@googlemail.com> Message-ID: <4F55D3B9.4050602@yahoo.com> On 03/06/2012 05:13 AM, Mr Dash Four wrote: > I am trying to build a static version of ssh, sshd and sftp, but after banging my head against the wall for the best part of the last 3 days I am about to give up... Lately, I have been working on a Perl module that does just that. It is still a work in progress. My aim was to be able to create easy to install binaries for platforms that do not include recent versions of OpenSSH (Solaris, HP-UX, AIX, etc.), but it may serve you as well. At least you will see a set of flags and configure options that work on Unix systems. In order to use it, you will have to download the following two modules from github https://github.com/salva/p5-Module-StaticBinaryBuilder https://github.com/salva/p5-Net-OpenSSH-StaticBinary Install the first module and then run the StaticBuild.PL script from the second. It will take care of downloading the packages (openssl and openssh), and compile them from scratch with the proper options. From mr.dash.four at googlemail.com Wed Mar 7 01:58:55 2012 From: mr.dash.four at googlemail.com (Mr Dash Four) Date: Tue, 06 Mar 2012 14:58:55 +0000 Subject: openssh static build - mission impossible? In-Reply-To: <20120306075248.9797.qmail@stuge.se> References: <4F558EF0.3000308@googlemail.com> <20120306052826.30761.qmail@stuge.se> <4F55A3EE.6080506@googlemail.com> <20120306060004.945.qmail@stuge.se> <4F55AF75.1080202@googlemail.com> <20120306075248.9797.qmail@stuge.se> Message-ID: <4F56262F.5090905@googlemail.com> > ..multilib or no, the libcrypt.a being used is from /usr/lib and > since you say that this means armv7l then I don't think that is a > library you want to use on the armv6l target. Where did I say that my libcrypt.a is from armv7l? > The compiler used > having yet another tuple (armv5tel) doesn't reduce potential > problems and question marks. > The compiler *never* used the armv5tel tuple as it wasn't specified anywhere! If you are going to teach me how to investigate a particular issue, I'd suggest you take a leaf out of that book yourself and do it properly! I have already told you that my compiler is multilib capable and the libcrypto.a in question is armv5tel, because that is what Fedora's stable repository for arm offers. It is accepted by the compiler and there won't be any issues, because of the arch used (armv5tel can be run on armv6l machine without issues - I thought you already know that, the fountain of knowledge that you are). > I've pointed to multiple issues worth investigating, and I've > explained one certain and one further possible high level solution > to your problem even if you choose to completely ignore the issues > worth investigating. > You've "pointed" me to absolutely nothing of note - you spend your last 3 posts pontificating instead of pointing out anything of substance or anything I already didn't know about. On a quite a few of those posts you were completely and utterly wrong. As I suggested in my previous post - if you are unwilling or incapable of contributing anything of substance, then don't bother replying. From mr.dash.four at googlemail.com Wed Mar 7 02:04:35 2012 From: mr.dash.four at googlemail.com (Mr Dash Four) Date: Tue, 06 Mar 2012 15:04:35 +0000 Subject: openssh static build - mission impossible? In-Reply-To: References: <4F558EF0.3000308@googlemail.com> <20120306052826.30761.qmail@stuge.se> <4F55A3EE.6080506@googlemail.com> <20120306060004.945.qmail@stuge.se> <4F55AF75.1080202@googlemail.com> Message-ID: <4F562783.2020208@googlemail.com> > Peter, a similar [abnormal] discussion was at OpenVPN list[1] > Really? The "discussion" in question on that list was due to Alon modifying the openvpn source code and flogging it to the general public as if this is an official openvpn release, without telling anyone the code has been modified. When I pulled Alon up on that, he reverted to petty insults. Alon was then told by the moderators on that list to shut his gob (not for the first time, I might add) in order not to get embarrassed even further. From mr.dash.four at googlemail.com Wed Mar 7 02:13:17 2012 From: mr.dash.four at googlemail.com (Mr Dash Four) Date: Tue, 06 Mar 2012 15:13:17 +0000 Subject: openssh static build - mission impossible? In-Reply-To: <4F55CD7B.4030500@symas.com> References: <4F558EF0.3000308@googlemail.com> <20120306052826.30761.qmail@stuge.se> <4F55A3EE.6080506@googlemail.com> <20120306060004.945.qmail@stuge.se> <4F55CD7B.4030500@symas.com> Message-ID: <4F56298D.1010403@googlemail.com> > Sounds like he's been bitten by RedHat/Fedora's policy to replace all > crypto on the system with MozillaNSS. I can confirm that is indeed the case, sadly! I spend this morning looking at the libc files and the references are there for all to see. Why Fedora choose to do it that way I'd never know! > You could easily dig up an unmodified glibc source to replace this. By "unmodified" I presume you mean free of the nss dependencies Fedora introduced, right? Is there a way to recompile libc, but exclude those dependencies (replacing libc completely is going to open a whole new can of worms, I think). > Also, the suggestion to use uClibc is still a better one. It will make > static linking that much easier as well. Another option is to grab > Bionic from the Android source tree; either of these is more compact > than the stock Fedora monstrosity. The problem with this approach is that I already use a compiler as well as all sorts of other applications, which rely on a particular version of libc present. I am not sure if I can just replace it with something else. If I could recompile the same libc version, but somehow "strip" the nss dependencies, I think that would be the best course of action without causing mayhem. From mr.dash.four at googlemail.com Wed Mar 7 02:14:08 2012 From: mr.dash.four at googlemail.com (Mr Dash Four) Date: Tue, 06 Mar 2012 15:14:08 +0000 Subject: openssh static build - mission impossible? In-Reply-To: <4F55D3B9.4050602@yahoo.com> References: <4F558EF0.3000308@googlemail.com> <4F55D3B9.4050602@yahoo.com> Message-ID: <4F5629C0.5010509@googlemail.com> > Lately, I have been working on a Perl module that does just that. > > It is still a work in progress. My aim was to be able to create easy to > install binaries for platforms that do not include recent versions of > OpenSSH (Solaris, HP-UX, AIX, etc.), but it may serve you as well. At > least you will see a set of flags and configure options that work on > Unix systems. > > In order to use it, you will have to download the following two modules > from github > > https://github.com/salva/p5-Module-StaticBinaryBuilder > https://github.com/salva/p5-Net-OpenSSH-StaticBinary > > Install the first module and then run the StaticBuild.PL script from the > second. It will take care of downloading the packages (openssl and > openssh), and compile them from scratch with the proper options. > Thanks, I'll look into this one - much appreciated! From gert at greenie.muc.de Wed Mar 7 02:19:23 2012 From: gert at greenie.muc.de (Gert Doering) Date: Tue, 6 Mar 2012 16:19:23 +0100 Subject: openssh static build - mission impossible? In-Reply-To: <4F562783.2020208@googlemail.com> References: <4F558EF0.3000308@googlemail.com> <20120306052826.30761.qmail@stuge.se> <4F55A3EE.6080506@googlemail.com> <20120306060004.945.qmail@stuge.se> <4F55AF75.1080202@googlemail.com> <4F562783.2020208@googlemail.com> Message-ID: <20120306151923.GI1359@greenie.muc.de> Hi, On Tue, Mar 06, 2012 at 03:04:35PM +0000, Mr Dash Four wrote: > >Peter, a similar [abnormal] discussion was at OpenVPN list[1] > > > Really? The "discussion" in question on that list was due to Alon > modifying the openvpn source code and flogging it to the general public > as if this is an official openvpn release, without telling anyone the > code has been modified. > > When I pulled Alon up on that, he reverted to petty insults. Alon was > then told by the moderators on that list to shut his gob (not for the > first time, I might add) in order not to get embarrassed even further. Actually, Samuli and I tried to explain to *you* that you completely missed the boat there. So please stop spreading FUD on unrelated lists. (Apologies to the OpenSSH people on this list that this is spilling over from the OpenVPN list) gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert at net.informatik.tu-muenchen.de From mr.dash.four at googlemail.com Wed Mar 7 02:25:08 2012 From: mr.dash.four at googlemail.com (Mr Dash Four) Date: Tue, 06 Mar 2012 15:25:08 +0000 Subject: openssh static build - mission impossible? In-Reply-To: <20120306151923.GI1359@greenie.muc.de> References: <4F558EF0.3000308@googlemail.com> <20120306052826.30761.qmail@stuge.se> <4F55A3EE.6080506@googlemail.com> <20120306060004.945.qmail@stuge.se> <4F55AF75.1080202@googlemail.com> <4F562783.2020208@googlemail.com> <20120306151923.GI1359@greenie.muc.de> Message-ID: <4F562C54.2040004@googlemail.com> > Actually, Samuli and I tried to explain to *you* that you completely > missed the boat there. So please stop spreading FUD on unrelated lists. > Samuli and *you*?! Would you like me to forward you what I had from Samuli on that particular topic? As for spreading FUD to "unrelated lists" - I am not the one who started this and when someone like Alon really starts "spreading FUD" I had to put him in his place - for his own sake. > (Apologies to the OpenSSH people on this list that this is spilling over > from the OpenVPN list) > Ditto! From peter at stuge.se Wed Mar 7 04:58:42 2012 From: peter at stuge.se (Peter Stuge) Date: Tue, 6 Mar 2012 18:58:42 +0100 Subject: openssh static build - mission impossible? In-Reply-To: <4F56262F.5090905@googlemail.com> References: <4F558EF0.3000308@googlemail.com> <20120306052826.30761.qmail@stuge.se> <4F55A3EE.6080506@googlemail.com> <20120306060004.945.qmail@stuge.se> <4F55AF75.1080202@googlemail.com> <20120306075248.9797.qmail@stuge.se> <4F56262F.5090905@googlemail.com> Message-ID: <20120306175842.30196.qmail@stuge.se> Mr Dash Four wrote: >> ..multilib or no, the libcrypt.a being used is from /usr/lib and >> since you say that this means armv7l then I don't think that is a >> library you want to use on the armv6l target. > > Where did I say that my libcrypt.a is from armv7l? I asked you what tuple you build with and you said armv7l, but that turned out to be wrong; you're using armv5tel to build. It may be running on an armv7l machine, but I asked in the context of the parameters you were giving to configure, so it's all about the toolchain here, not about the machine. If your intention is indeed to build using the armv5tel compiler and libraries then you probably shouldn't specify --build with armv7l. When cross-compiling using autotools --host is what is most important. >> The compiler used having yet another tuple (armv5tel) doesn't >> reduce potential problems and question marks. > > The compiler *never* used the armv5tel tuple as it wasn't specified > anywhere! It does use this tuple, because the tuple was specified when the compiler was built, multilib or not. Look at the original output you sent to the list and you'll find armv5tel mentioned. > I have already told you that my compiler is multilib capable and the > libcrypto.a in question is armv5tel, Actually you didn't tell me this about libcrypto.a, I was told by the compiler output. > It is accepted by the compiler and there won't be any issues, > because of the arch used (armv5tel can be run on armv6l machine > without issues Right, but then you aren't building with an armv6l tuple cross-toolchain, so I would then also not use --host. Normally when cross-compiling for a specific target, you also have a specific toolchain for that target, as well as have built all system libraries you want for that target which your package depends on. It's clear now that you are using the unusual approach of trying to reuse Fedora binaries for OpenSSH dependencies, in order to build an OpenSSH binary targeted for a very different environment (bionic) than Fedora. It's no surprise that this blows up in your face. If you had been clear about your method you could have gotten the following advice much sooner. I assumed you had taken the more thorough approach, my bad. You'll have much better success if you yourself build the dependencies for OpenSSH. This is the usual way to build a distribution. You only want to build OpenSSH and not a distribution, but since you want the OpenSSH binary in a special way you effectively must also build a small distribution (meaning in this case a set of libraries) which allows building OpenSSH the way you want. The Fedora binaries do not. > You've "pointed" me to absolutely nothing of note I'm sorry if you feel that I've wasted your time. Maybe you didn't understand my advice. > As I suggested in my previous post - if you are unwilling or > incapable of contributing anything of substance, then don't > bother replying. That's not an excellent comment. You're overlooking the possibility that I have given good advice which you misunderstood. I think you may also overlook the right to free speech. But I digress. If you refuse to build your own libcrypto then you really have no way to accomplish your goal; the libcrypto you try to use (Fedora's binary) has a dependency (NSS) which is incompatible with your goal, leaving you the only choice of building your own, as I suggested that you should already several emails ago. Did you check already if OpenSSH actually includes a crypt() implementation in the compat sources? If it doesn't, then again I'd suggest to build your own small library named, say, libmrdashfourcrypt which only includes a self-contained crypt() implementation from one of the many sources of this function available on the interwebs. You don't have to write it from scratch, just copy a working implementation from a project with a compatible license. The BSD projects come to mind, and there's also HelenOS. Good luck! I hope you'll get it to work. //Peter From reza.hedayat at adnovum.ch Wed Mar 7 04:57:35 2012 From: reza.hedayat at adnovum.ch (Reza Hedayat) Date: Tue, 06 Mar 2012 18:57:35 +0100 Subject: Invalid user name: function okname() in scp.c Message-ID: <4F56500F.9040808@adnovum.ch> Hi OpenSSH developers In the source file *scp.c* there is a function called *okname(char *cp0)* that validates the entered username by using the scp command as follows: * *[ Fragment scp.c start ] ... int okname(char *cp0) { int c; char *cp; cp = cp0; do { c = (int)*cp; if (c & 0200) goto bad; if (!isalpha(c) && !isdigit(c)) { switch (c) { case '\'': case '"': case '`': case ' ': * case '#':* goto bad; default: break; } } } while (*++cp); return (1); bad: fprintf(stderr, "%s: invalid user name\n", cp0); return (0); } ... [ Fragment scp.c end ] Thereby, usernames that contain the hash sign (#) are rejected. Is there a good reason why this logic was introduced? If there is no reason, so is it possible to remove the mentioned case-statement? I thank you in advance for your help and remain with best wishes Reza Hedayat From keisial at gmail.com Wed Mar 7 05:33:33 2012 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Tue, 06 Mar 2012 19:33:33 +0100 Subject: openssh static build - mission impossible? In-Reply-To: <4F56298D.1010403@googlemail.com> References: <4F558EF0.3000308@googlemail.com> <20120306052826.30761.qmail@stuge.se> <4F55A3EE.6080506@googlemail.com> <20120306060004.945.qmail@stuge.se> <4F55CD7B.4030500@symas.com> <4F56298D.1010403@googlemail.com> Message-ID: <4F56587D.70101@gmail.com> On 06/03/12 16:13, Mr Dash Four wrote: >> You could easily dig up an unmodified glibc source to replace this. > By "unmodified" I presume you mean free of the nss dependencies Fedora > introduced, right? Is there a way to recompile libc, but exclude those > dependencies (replacing libc completely is going to open a whole new > can of worms, I think). > >> Also, the suggestion to use uClibc is still a better one. It will >> make static linking that much easier as well. Another option is to >> grab Bionic from the Android source tree; either of these is more >> compact than the stock Fedora monstrosity. > The problem with this approach is that I already use a compiler as > well as all sorts of other applications, which rely on a particular > version of libc present. I am not sure if I can just replace it with > something else. If I could recompile the same libc version, but > somehow "strip" the nss dependencies, I think that would be the best > course of action without causing mayhem. Recompiling the same glibc version, but from upstream[1] instead of Fedora should theoretically work. Although I agree replacing glibc is not without risks. You could try to install a libc at a separate path, there is surely a way to do that, yet still cross-compile right. Finally, the tone of several of your messages to this ml have been more rude than needed. Please try to keep civility. 1- http://www.gnu.org/software/libc From keisial at gmail.com Wed Mar 7 05:40:46 2012 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Tue, 06 Mar 2012 19:40:46 +0100 Subject: Invalid user name: function okname() in scp.c In-Reply-To: <4F56500F.9040808@adnovum.ch> References: <4F56500F.9040808@adnovum.ch> Message-ID: <4F565A2E.5040800@gmail.com> On 06/03/12 18:57, Reza Hedayat wrote: > Hi OpenSSH developers > > In the source file *scp.c* there is a function called *okname(char > *cp0)* that validates the entered username by using the scp command as > follows: > > ( Fragment scp.c skipped) > > Thereby, usernames that contain the hash sign (#) are rejected. Is > there a good reason why this logic was introduced? > If there is no reason, so is it possible to remove the mentioned > case-statement? > > I thank you in advance for your help and remain with best wishes > Reza Hedayat It's trying to avoiod shell special characters (quotes, backticks, spaces...). The # introduces a comment in the shell (would need escaping), so that's surely the reason it's forbidden. You could replace it if you were sure the username is never used unquoted. Having a # in the user name is very rare, though. From keisial at gmail.com Wed Mar 7 05:45:54 2012 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Tue, 06 Mar 2012 19:45:54 +0100 Subject: openssh static build - mission impossible? In-Reply-To: <20120306175842.30196.qmail@stuge.se> References: <4F558EF0.3000308@googlemail.com> <20120306052826.30761.qmail@stuge.se> <4F55A3EE.6080506@googlemail.com> <20120306060004.945.qmail@stuge.se> <4F55AF75.1080202@googlemail.com> <20120306075248.9797.qmail@stuge.se> <4F56262F.5090905@googlemail.com> <20120306175842.30196.qmail@stuge.se> Message-ID: <4F565B62.4030704@gmail.com> On 06/03/12 18:58, Peter Stuge wrote: > But I digress. If you refuse to build your own libcrypto then you > really have no way to accomplish your goal; the libcrypto you try > to use (Fedora's binary) has a dependency (NSS) which is incompatible > with your goal, leaving you the only choice of building your own, as > I suggested that you should already several emails ago. Did you check > already if OpenSSH actually includes a crypt() implementation in the > compat sources? openssl DES_crypt() (at crypto/des/fcrypt.c, but you (Mr Dash Four) are already linking with openssl) seems to be a crypt(3) implementation. From peter at stuge.se Wed Mar 7 05:51:03 2012 From: peter at stuge.se (Peter Stuge) Date: Tue, 6 Mar 2012 19:51:03 +0100 Subject: openssh static build - mission impossible? In-Reply-To: <4F56587D.70101@gmail.com> References: <4F558EF0.3000308@googlemail.com> <20120306052826.30761.qmail@stuge.se> <4F55A3EE.6080506@googlemail.com> <20120306060004.945.qmail@stuge.se> <4F55CD7B.4030500@symas.com> <4F56298D.1010403@googlemail.com> <4F56587D.70101@gmail.com> Message-ID: <20120306185103.2526.qmail@stuge.se> ?ngel Gonz?lez wrote: > Recompiling the same glibc version, but from upstream[1] instead of > Fedora should theoretically work. Although I agree replacing glibc is > not without risks. I think libc can be left alone, all that is needed is a crypt() implementation. If DES_crypt() can be used as-is then the missing piece of the puzzle is a trivial wrapper. //Peter From mr.dash.four at googlemail.com Wed Mar 7 06:06:11 2012 From: mr.dash.four at googlemail.com (Mr Dash Four) Date: Tue, 06 Mar 2012 19:06:11 +0000 Subject: openssh static build - mission impossible? In-Reply-To: <4F56587D.70101@gmail.com> References: <4F558EF0.3000308@googlemail.com> <20120306052826.30761.qmail@stuge.se> <4F55A3EE.6080506@googlemail.com> <20120306060004.945.qmail@stuge.se> <4F55CD7B.4030500@symas.com> <4F56298D.1010403@googlemail.com> <4F56587D.70101@gmail.com> Message-ID: <4F566023.4040307@googlemail.com> > Recompiling the same glibc version, but from upstream[1] instead of > Fedora should theoretically work. Although I agree replacing glibc is > not without risks. > You could try to install a libc at a separate path, there is surely a > way to do that, yet still cross-compile right. > OK, I am currently coming round two alternatives and they are not ideal (at least I am in the dark with a few issues which need to be dealt with). As Howard Chu suggested earlier, I am considering uClibc, mainly for the small footprint as well as the possibility to later statically link other tools. As it turns out, there is uClibc package on Fedora, so I just need to compile this. By the looks of it, it installs in /usr/lib/uClibc by default. Another alternative is, as you suggested above, to compile a "different" glibc library using the gcc source from the link you provided earlier and install it in a different directory (say /usr/lib/glibc_mod). The question for me now is this - is there a way to force the *existing* gcc to use these new libraries, without reverting to its own version of them (/usr/lib/gcc/armv5tel-redhat-linux-gnueabi/4.6.1/../../../libc*)? If so, how do I do it - via -L/usr/lib/UClibc or -L/usr/lib/glibc_mod or by doing something else? Personally, if I could force the existing gcc to use uClibc and use this library to compile openssh and produce a static binary I will be well-happy, though I still don't know whether I would need to use the crypto library, which was "integrated" into the "old" libc previously? > Finally, the tone of several of your messages to this ml have been more > rude than needed. Please try to keep civility. > I am usually courteous to others, but if the same isn't forthcoming (as was the case with Peter and Alon) I make sure I swiftly return the favour - having to deal with Internet warriors is not what I registered on this ML for. From mr.dash.four at googlemail.com Wed Mar 7 06:09:27 2012 From: mr.dash.four at googlemail.com (Mr Dash Four) Date: Tue, 06 Mar 2012 19:09:27 +0000 Subject: openssh static build - mission impossible? In-Reply-To: <4F565B62.4030704@gmail.com> References: <4F558EF0.3000308@googlemail.com> <20120306052826.30761.qmail@stuge.se> <4F55A3EE.6080506@googlemail.com> <20120306060004.945.qmail@stuge.se> <4F55AF75.1080202@googlemail.com> <20120306075248.9797.qmail@stuge.se> <4F56262F.5090905@googlemail.com> <20120306175842.30196.qmail@stuge.se> <4F565B62.4030704@gmail.com> Message-ID: <4F5660E7.8030008@googlemail.com> >> But I digress. If you refuse to build your own libcrypto then you >> really have no way to accomplish your goal; the libcrypto you try >> to use (Fedora's binary) has a dependency (NSS) which is incompatible >> with your goal, leaving you the only choice of building your own, as >> I suggested that you should already several emails ago. Did you check >> already if OpenSSH actually includes a crypt() implementation in the >> compat sources? >> > openssl DES_crypt() (at crypto/des/fcrypt.c, but you (Mr Dash Four) are > already linking with openssl) seems to be a crypt(3) implementation. > I have specifically rebuilt openssl so that I could use its static libraries to compile openssh - that was the main goal (the standard Fedora-distributed openssl was way too bloated, again). So, given the above, bearing in mind what I just posted in my previous post, do I need another static crypto library to link against? From mr.dash.four at googlemail.com Wed Mar 7 06:25:34 2012 From: mr.dash.four at googlemail.com (Mr Dash Four) Date: Tue, 06 Mar 2012 19:25:34 +0000 Subject: openssh static build - mission impossible? In-Reply-To: <20120306175842.30196.qmail@stuge.se> References: <4F558EF0.3000308@googlemail.com> <20120306052826.30761.qmail@stuge.se> <4F55A3EE.6080506@googlemail.com> <20120306060004.945.qmail@stuge.se> <4F55AF75.1080202@googlemail.com> <20120306075248.9797.qmail@stuge.se> <4F56262F.5090905@googlemail.com> <20120306175842.30196.qmail@stuge.se> Message-ID: <4F5664AE.6060809@googlemail.com> > Normally when cross-compiling for a specific target, you also have a > specific toolchain for that target, as well as have built all system > libraries you want for that target which your package depends on. > Except in cases where the compiler is multilib, in which case that isn't really needed. > It's clear now that you are using the unusual approach of trying to > reuse Fedora binaries for OpenSSH dependencies, in order to build > an OpenSSH binary targeted for a very different environment (bionic) > than Fedora. Nope! I am trying to build a static openssh to run on armv6l - the "environment", whether bionic, OpenWRT or something else - is completely irrelevant to me and this is how it should be with monolithic statically-build binaries. > It's no surprise that this blows up in your face. > > If you had been clear about your method you could have gotten the > following advice much sooner. I assumed you had taken the more > thorough approach, my bad. > What advice?! Not from you anyway - you have posted 4 times in this thread without giving *any* sort of advice whatsoever - just pontificating. > You'll have much better success if you yourself build the > dependencies for OpenSSH. This is the usual way to build a > distribution. That is already done. As I already pointed out - the only exception being is that I did not know how bloated my Fedora-supplied libc would be, so that it introduces undesired NSS dependencies which I need to get rid of in order to succeed. > You only want to build OpenSSH and not a distribution, > but since you want the OpenSSH binary in a special way you > effectively must also build a small distribution (meaning in this > case a set of libraries) which allows building OpenSSH the way you > want. I don't consider the way I build openssh (or any other package or binary for that matter) to be "special" - I would have succeeded if it wasn't for the fact that Fedora decided to ditch the entire crypto stack, implement Mozilla's NSS *and* link it with the standard libc library. > That's not an excellent comment. You're overlooking the possibility > that I have given good advice which you misunderstood. Which is what, exactly? Please enlighten me, because I fail to see what was the "advice" you have given me - going by what you've posted so far, I could see none whatsoever. > I think you > may also overlook the right to free speech. > You are not the one to lecture me about free speech - who the hell do you think you are?! > But I digress. If you refuse to build your own libcrypto then you > really have no way to accomplish your goal; Where did I "refuse" to build my own crypto - are you to continue making things up as you go along? From cmadams at hiwaay.net Wed Mar 7 07:11:28 2012 From: cmadams at hiwaay.net (Chris Adams) Date: Tue, 6 Mar 2012 14:11:28 -0600 Subject: openssh static build - mission impossible? In-Reply-To: <4F5664AE.6060809@googlemail.com> References: <4F558EF0.3000308@googlemail.com> <20120306052826.30761.qmail@stuge.se> <4F55A3EE.6080506@googlemail.com> <20120306060004.945.qmail@stuge.se> <4F55AF75.1080202@googlemail.com> <20120306075248.9797.qmail@stuge.se> <4F56262F.5090905@googlemail.com> <20120306175842.30196.qmail@stuge.se> <4F5664AE.6060809@googlemail.com> Message-ID: <20120306201128.GE15636@hiwaay.net> Once upon a time, Mr Dash Four said: > I don't consider the way I build openssh (or any other package or binary > for that matter) to be "special" - I would have succeeded if it wasn't > for the fact that Fedora decided to ditch the entire crypto stack, > implement Mozilla's NSS *and* link it with the standard libc library. You appear to be confusing two things that unfortunately share the name "nss": - Name Switch Service: method for using a variety of sources of information for common things like users/passwords, hostnames/IPs, etc. This is an integral part of the GNU C library, and uses dynamic loading to support different lookup methods (e.g. files, NIS, LDAP, DNS, etc.). If you don't want any dynamic loading, don't use the GNU C library (use something like uclibc instead). I believe that's the offocial position of the authors. - Network Security Services: a cross-platform encryption library, originally written by Netscape. This AFAIK does not use any additional dynamic loading, although I don't know if they support building static libraries (static linking is considered bad for security, as a bug means lots of packages have to be rebuilt). The names are both rather old at this point (Name Switch Service originates with Solaris, IIRC from the early days of Solaris 2). The only Fedora-specific thing here is that they have moved towards using the NSS encryption library instead of OpenSSL for many packages for a number of reasons (especially more stable ABI and because it is FIPS validated, which is needed for RHEL). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From Paul-Ebermann at gmx.de Wed Mar 7 09:42:02 2012 From: Paul-Ebermann at gmx.de (Paul Ebermann) Date: Tue, 06 Mar 2012 23:42:02 +0100 Subject: Unix socket forwarding In-Reply-To: <20120306000441.4336.qmail@stuge.se> References: <20120305092152.GA10207@ortolo.eu> <4F54FB2F.5060300@fifthhorseman.net> <20120305194405.GA702@wilbur.25thandClement.com> <4F551D30.1030304@fifthhorseman.net> <20120305211137.GA32652@wilbur.25thandClement.com> <20120306000441.4336.qmail@stuge.se> Message-ID: <4F5692BA.3060605@gmx.de> Peter Stuge skribis: >> and yet I've been the only one to cook up a patch, tends to >> suggest a lack of substantive demand. > > I think this is spot on. If I would need to do this I would indeed > use socat, possibly as an ssh subsystem. Would this be something like the sftp subsystem? Would we need special client support then, or just some server configuration? Pa?lo From nkadel at gmail.com Wed Mar 7 12:29:10 2012 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Tue, 6 Mar 2012 20:29:10 -0500 Subject: openssh static build - mission impossible? In-Reply-To: <20120306185103.2526.qmail@stuge.se> References: <4F558EF0.3000308@googlemail.com> <20120306052826.30761.qmail@stuge.se> <4F55A3EE.6080506@googlemail.com> <20120306060004.945.qmail@stuge.se> <4F55CD7B.4030500@symas.com> <4F56298D.1010403@googlemail.com> <4F56587D.70101@gmail.com> <20120306185103.2526.qmail@stuge.se> Message-ID: On Tue, Mar 6, 2012 at 1:51 PM, Peter Stuge wrote: > ?ngel Gonz?lez wrote: > > Recompiling the same glibc version, but from upstream[1] instead of > > Fedora should theoretically work. Although I agree replacing glibc is > > not without risks. > > I think libc can be left alone, all that is needed is a crypt() > implementation. If DES_crypt() can be used as-is then the missing > piece of the puzzle is a trivial wrapper. > It does seem to be turning into a seroius project. Building from SRPM spec files, cross-compiling, and trying to do a static build seems like a very long chain of links of chain to shove through a slot: one link might pass, but passing two or three in a row seems like an akward attempt. Is it possible to factor the problem? To compile on the same platform you're aiming for, to avoid the cross-compiler issues or to compile cleanly without the cross-compilaton? Is it possible to compile with bare source, not using the SRPM structure? And is it possible to build properly with the shared libraries, just so that each factor can be scaled back one at a time? From peter at stuge.se Wed Mar 7 14:11:58 2012 From: peter at stuge.se (Peter Stuge) Date: Wed, 7 Mar 2012 04:11:58 +0100 Subject: openssh static build - mission impossible? In-Reply-To: <4F5664AE.6060809@googlemail.com> References: <4F558EF0.3000308@googlemail.com> <20120306052826.30761.qmail@stuge.se> <4F55A3EE.6080506@googlemail.com> <20120306060004.945.qmail@stuge.se> <4F55AF75.1080202@googlemail.com> <20120306075248.9797.qmail@stuge.se> <4F56262F.5090905@googlemail.com> <20120306175842.30196.qmail@stuge.se> <4F5664AE.6060809@googlemail.com> Message-ID: <20120307031158.9423.qmail@stuge.se> Mr Dash Four wrote: >> It's clear now that you are using the unusual approach of trying to >> reuse Fedora binaries for OpenSSH dependencies, in order to build >> an OpenSSH binary targeted for a very different environment (bionic) >> than Fedora. > > Nope! I am trying to build a static openssh to run on armv6l - the > "environment", whether bionic, OpenWRT or something else - is > completely irrelevant to me This is your mistake. The environment is quite significant during the build process... > and this is how it should be with monolithic statically-build > binaries. ...but once the binaries have been built, *then* the environment is more or less irrelevant. However, since you are doing the building, you have to be quite thorough about the environment. >> If you had been clear about your method you could have gotten the >> following advice much sooner. I assumed you had taken the more >> thorough approach, my bad. > > What advice?! This: >> You'll have much better success if you yourself build the >> dependencies for OpenSSH. This is the usual way to build a >> distribution. I also suggested how you should do this in a very early email. I suggested it again in the email you replied to. I'll repeat it one more time below. > Not from you anyway - you have posted 4 times in this thread > without giving *any* sort of advice whatsoever - just > pontificating. I'll repeat it (with new wording) again below. Hopefully this time it will be more clear. >> You'll have much better success if you yourself build the >> dependencies for OpenSSH. This is the usual way to build a >> distribution. > > That is already done. No, since you use libcrypt (and libc) from Fedora. > As I already pointed out - the only exception being Exactly, there's an exception, so it isn't already done. >> You only want to build OpenSSH and not a distribution, >> but since you want the OpenSSH binary in a special way you >> effectively must also build a small distribution (meaning in this >> case a set of libraries) which allows building OpenSSH the way you >> want. > > I don't consider the way I build openssh (or any other package or > binary for that matter) to be "special" It is special because you have requirements other than what Fedora already delivers. In this case you can also substitute "particular" for "special" if you like. > I would have succeeded if it wasn't for the fact that Fedora > decided to ditch the entire crypto stack, implement Mozilla's > NSS *and* link it with the standard libc library. Yeah, this was clear already in the first or second email, where I first suggested how to proceed. >> That's not an excellent comment. You're overlooking the possibility >> that I have given good advice which you misunderstood. > > Which is what, exactly? Please enlighten me, because I fail to see > what was the "advice" you have given me - going by what you've > posted so far, I could see none whatsoever. Here goes again: Problem: OpenSSH calls crypt() but Fedora libcrypt.a doesn't work because of NSS. Advice: Provide your own crypt() implementation and build OpenSSH without Fedora's libcrypt.a. I've suggested several sources where you can look for an implementation, so that you don't have to write one from scratch. It was also pointed out that actually the OpenSSL you are using already includes a suitable implementation, DES_crypt(). So the simplest solution seems to be that you write a small wrapper function named crypt() with the correct API, which uses DES_crypt() in OpenSSL to do the work. Compile this function and link OpenSSH with the object file (it doesn't even have to be a library) - done. >> I think you may also overlook the right to free speech. > > You are not the one to lecture me about free speech - who the hell > do you think you are?! I'm the guy you said should not speak. >> But I digress. If you refuse to build your own libcrypto then you >> really have no way to accomplish your goal; > > Where did I "refuse" to build my own crypto As you can see I wrote "If" which is a condition. I did not claim that you had refused anything. I tried to clarify that you had somewhat few options on how to proceed. > - are you to continue making things up as you go along? It's a typo. I meant libcrypt, as in libcrypt.a. Since this is the library that you are having problems with this typo might have been evident from context. But I apologize for the extra byte causing confusion. //Peter From reza.hedayat at adnovum.ch Wed Mar 7 20:34:30 2012 From: reza.hedayat at adnovum.ch (Reza Hedayat) Date: Wed, 07 Mar 2012 10:34:30 +0100 Subject: Invalid user name: function okname() in scp.c In-Reply-To: <4F565A2E.5040800@gmail.com> References: <4F56500F.9040808@adnovum.ch> <4F565A2E.5040800@gmail.com> Message-ID: <4F572BA6.6010003@adnovum.ch> Hi ?ngel Thanks a lot for your quick answer. You're right, this use case is very rare, but unfortunately there exist some cases. :( Cheers Reza On 03/06/12 19:40, ?ngel Gonz?lez wrote: > On 06/03/12 18:57, Reza Hedayat wrote: >> Hi OpenSSH developers >> >> In the source file *scp.c* there is a function called *okname(char >> *cp0)* that validates the entered username by using the scp command as >> follows: >> >> ( Fragment scp.c skipped) >> >> Thereby, usernames that contain the hash sign (#) are rejected. Is >> there a good reason why this logic was introduced? >> If there is no reason, so is it possible to remove the mentioned >> case-statement? >> >> I thank you in advance for your help and remain with best wishes >> Reza Hedayat > It's trying to avoiod shell special characters (quotes, backticks, > spaces...). The # introduces a comment in the shell (would need > escaping), so that's surely the reason it's forbidden. > You could replace it if you were sure the username is never used unquoted. > Having a # in the user name is very rare, though. From chanpav at gmail.com Fri Mar 9 05:12:36 2012 From: chanpav at gmail.com (Chandana Pavuluru) Date: Thu, 8 Mar 2012 23:42:36 +0530 Subject: FIPS compliant OpenSSH Message-ID: Hi, How do I make OpenSSH FIPS compliant? Will just compiling with OpenSSL version that is built with a FIPS validated module, make it FIPS compliant? I see sshd linked to both libcrypt and libcrypto. How do I make sure sshd runs only in FIPS mode? Appreciate any help. Thanks, Chandana From djm at mindrot.org Fri Mar 9 10:34:53 2012 From: djm at mindrot.org (Damien Miller) Date: Fri, 9 Mar 2012 10:34:53 +1100 (EST) Subject: Call for testing: OpenSSH-6.0 In-Reply-To: <868vjxbkkd.fsf@ds4.des.no> References: <868vjxbkkd.fsf@ds4.des.no> Message-ID: On Mon, 20 Feb 2012, Dag-Erling Sm?rgrav wrote: > [resent without troublesome attachments] > > Damien Miller writes: > > OpenSSH 6.0 is almost ready for release, so we would appreciate testing > > on as many platforms and systems as possible. This release contains a > > couple of new features and changes and bug fixes. Testing of the new > > sandboxed privilege separation mode (see below) would be particularly > > appreciated. > > openssh-SNAP-20120221 fails to build on FreeBSD 9 and 10: the configure > script incorrectly concludes that FreeBSD doesn't have openpty(3), and > bsd-openpty.c doesn't build on FreeBSD. See http://www.des.no/openssh/ So, config.log says: > configure:9158: gcc -o conftest -g -O2 -Wall -Wpointer-arith -Wuninitialized > -Wsign-compare -Wformat-security -Wno-pointer-sign -fno-strict-aliasing > > -D_FORTIFY_SOURCE=2 -fno-builtin-memset -fstack-protector-all > > -fstack-protector-all conftest.c -lz >&5 > /tmp//ccnfm8sv.o: In function `main': > /home/des/src/openssh/conftest.c:137: undefined reference to `openpty' Does FreeBSD stick openpty in -lutil or somesuch? -d From djm at mindrot.org Fri Mar 9 10:36:24 2012 From: djm at mindrot.org (Damien Miller) Date: Fri, 9 Mar 2012 10:36:24 +1100 (EST) Subject: any hope for bug 1663 or similar function? In-Reply-To: <20120221135650.GA74606@bewilderbeast.blackhelicopters.org> References: <20120221135650.GA74606@bewilderbeast.blackhelicopters.org> Message-ID: On Tue, 21 Feb 2012, Michael W. Lucas wrote: > Hi folks, > > Is there any hope for an external source of public keys, such as given > in bug 1663? > > I have dozens of servers, and I have to patch sshd on the vast > majority of them. OpenSSH is a BSD program, but the BSD boxes are the > most difficult to manage because of this. Yes, I'm aware that this has been on my TODO list for too long. I hope to come up with some command or agent-based solution (ideally based on one of the existing patches) soon, but have had some other work queued ahead of it for a while. I hope I'll be able to do it for 6.1. -d From djm at mindrot.org Fri Mar 9 10:46:36 2012 From: djm at mindrot.org (Damien Miller) Date: Fri, 9 Mar 2012 10:46:36 +1100 (EST) Subject: Call for testing: OpenSSH-6.0 In-Reply-To: References: <868vjxbkkd.fsf@ds4.des.no> Message-ID: On Fri, 9 Mar 2012, Damien Miller wrote: > On Mon, 20 Feb 2012, Dag-Erling Sm?rgrav wrote: > > > openssh-SNAP-20120221 fails to build on FreeBSD 9 and 10: the configure > > script incorrectly concludes that FreeBSD doesn't have openpty(3), and > > bsd-openpty.c doesn't build on FreeBSD. See http://www.des.no/openssh/ > > So, config.log says: > > > configure:9158: gcc -o conftest -g -O2 -Wall -Wpointer-arith -Wuninitialized > > -Wsign-compare -Wformat-security -Wno-pointer-sign -fno-strict-aliasing > > > -D_FORTIFY_SOURCE=2 -fno-builtin-memset -fstack-protector-all > > > -fstack-protector-all conftest.c -lz >&5 > > /tmp//ccnfm8sv.o: In function `main': > > /home/des/src/openssh/conftest.c:137: undefined reference to `openpty' > > Does FreeBSD stick openpty in -lutil or somesuch? According to the manpages it does. Could you please try this? Index: configure.ac =================================================================== RCS file: /var/cvs/openssh/configure.ac,v retrieving revision 1.487 diff -u -p -r1.487 configure.ac --- configure.ac 23 Feb 2012 23:40:43 -0000 1.487 +++ configure.ac 8 Mar 2012 23:45:57 -0000 @@ -1127,7 +1127,11 @@ dnl Checks for libutil functions AC_CHECK_HEADERS([libutil.h]) AC_SEARCH_LIBS([login], [util bsd], [AC_DEFINE([HAVE_LOGIN], [1], [Define if your libraries define login()])]) -AC_CHECK_FUNCS([fmt_scaled logout updwtmp logwtmp]) +AC_SEARCH_LIBS([logout], [util]) +AC_SEARCH_LIBS([updwtmp], [util]) +AC_SEARCH_LIBS([logwtmp], [util]) +AC_SEARCH_LIBS([fmt_scaled], [util]) +AC_SEARCH_LIBS([openpty], [util]) AC_FUNC_STRFTIME @@ -1507,7 +1511,6 @@ AC_CHECK_FUNCS([ \ nsleep \ ogetaddrinfo \ openlog_r \ - openpty \ poll \ prctl \ pstat \ From des at des.no Fri Mar 9 22:30:12 2012 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Fri, 09 Mar 2012 12:30:12 +0100 Subject: Call for testing: OpenSSH-6.0 In-Reply-To: (Damien Miller's message of "Fri, 9 Mar 2012 10:34:53 +1100 (EST)") References: <868vjxbkkd.fsf@ds4.des.no> Message-ID: <86eht2yptn.fsf@ds4.des.no> Damien Miller writes: > Does FreeBSD stick openpty in -lutil or somesuch? Yes, I thought I'd mentioned that - sorry if I didn't. DES -- Dag-Erling Sm?rgrav - des at des.no From des at des.no Fri Mar 9 22:41:20 2012 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Fri, 09 Mar 2012 12:41:20 +0100 Subject: Call for testing: OpenSSH-6.0 In-Reply-To: (Damien Miller's message of "Fri, 9 Mar 2012 10:46:36 +1100 (EST)") References: <868vjxbkkd.fsf@ds4.des.no> Message-ID: <86aa3qypb3.fsf@ds4.des.no> Damien Miller writes: > According to the manpages it does. Could you please try this? If I apply the patch and run autoreconf, config.h.in no longer contains an entry for HAVE_OPENPTY, so although the configure script finds openpty() in libutil, it still tries to build bsd-compat/openpty.c. DES -- Dag-Erling Sm?rgrav - des at des.no From mr.dash.four at googlemail.com Sat Mar 10 01:43:27 2012 From: mr.dash.four at googlemail.com (Mr Dash Four) Date: Fri, 09 Mar 2012 14:43:27 +0000 Subject: Call for testing: OpenSSH-6.0 In-Reply-To: References: <868vjxbkkd.fsf@ds4.des.no> Message-ID: <4F5A170F.3040103@googlemail.com> > According to the manpages it does. Could you please try this? > Not related to the above issue in particular, but I submitted a bug with Fedora yesterday (see https://bugzilla.redhat.com/show_bug.cgi?id=801633) - it prevents cross-compilation/build of OpenSSH on "incompatible" platforms (i.e. build=anything_86, host=arm or host=ppc for example) due to execution of a binary (fips_standalone_sha1 - fips calculating hmac hashes) or platforms with different versions of Lib C (say, glibc on "build" and uclibc on "host"). The "solution" I proposed there is very ugly and I do not like it one bit, though I have no idea how this can be resolved. From mr.dash.four at googlemail.com Sat Mar 10 01:50:43 2012 From: mr.dash.four at googlemail.com (Mr Dash Four) Date: Fri, 09 Mar 2012 14:50:43 +0000 Subject: Call for testing: OpenSSH-6.0 In-Reply-To: <4F5A170F.3040103@googlemail.com> References: <868vjxbkkd.fsf@ds4.des.no> <4F5A170F.3040103@googlemail.com> Message-ID: <4F5A18C3.9030109@googlemail.com> Mr Dash Four wrote: > >> According to the manpages it does. Could you please try this? >> > Not related to the above issue in particular, but I submitted a bug > with Fedora yesterday (see > https://bugzilla.redhat.com/show_bug.cgi?id=801633) - it prevents > cross-compilation/build of OpenSSH on "incompatible" platforms (i.e. > build=anything_86, host=arm or host=ppc for example) due to execution > of a binary (fips_standalone_sha1 - fips calculating hmac hashes) or > platforms with different versions of Lib C (say, glibc on "build" and > uclibc on "host"). > > The "solution" I proposed there is very ugly and I do not like it one > bit, though I have no idea how this can be resolved. Scratch what I have just posted above - it is related to openssl, not openssh - I must fully wake up before posting! Apologies for the noise! From mr.dash.four at googlemail.com Mon Mar 12 02:15:18 2012 From: mr.dash.four at googlemail.com (Mr Dash Four) Date: Sun, 11 Mar 2012 15:15:18 +0000 Subject: openssh static build - mission impossible? In-Reply-To: <4F55CD7B.4030500@symas.com> References: <4F558EF0.3000308@googlemail.com> <20120306052826.30761.qmail@stuge.se> <4F55A3EE.6080506@googlemail.com> <20120306060004.945.qmail@stuge.se> <4F55CD7B.4030500@symas.com> Message-ID: <4F5CC186.3020909@googlemail.com> > Sounds like he's been bitten by RedHat/Fedora's policy to replace all > crypto on the system with MozillaNSS. You could easily dig up an > unmodified glibc source to replace this. Also, the suggestion to use > uClibc is still a better one. It will make static linking that much > easier as well. That was a very good suggestion as it turned out! What I did was to build a new toolchain for my target arch, based on uclibc and then recompile the whole dependency tree, starting from zlib, openssl etc. Quite a few tweaks and a few newly-discovered distro-specific OpenSSH bugs later (which I'll report on bugzilla in the coming days) I have brand new statically-linked openssh rpm packages (strictly speaking I did not need openssh to be packaged in rpm, but I am so used to rpmbuild). The size of the executables is indeed much smaller with uclibc - a simple statically-linked "hello, world" application is just over 17k with uclibc, while with glibc it was over 470k. As part of the "standard" build, there is hmac hash produced for the main openssh executables and object files - I did not install these .hmac files on the target device and from what I gather ssh(d) is not asking for them or refusing to run, so what is the purpose of these? The newly-built sshd is running fine, though since I do not have shadow passwords or any nss running on the target device, I had to "improvise" and create these files manually so that ssh(d) could run - otherwise I was getting a message saying ssh does not recognise me, asking me to "go away" (ha!). I am left with one very weird problem though: When I use a "Match" statement, which matches on anything from "Address", "Host" or "User", sshd chokes and exits with segfault error! Here is what I get after running sshd with "-ddd": debug3: checking match for 'Address 10.1.1.7' user root host 10.1.1.7 addr 10.1.1.7 debug1: connection from 10.1.1.7 matched 'Address 10.1.1.7' at line 132 debug3: match found debug3: reprocess config:133 setting PermitRootLogin yes debug3: reprocess config:134 setting AllowTcpForwarding yes debug3: reprocess config:135 setting AllowAgentForwarding yes debug3: reprocess config:136 setting AuthorizedKeysFile /etc/ssh/dmz_keys debug3: reprocess config:137 setting ChrootDirectory none /etc/rc.d/init.d/sshd: line 19: 5528 Segmentation fault $SSHD $OPTIONS This is the relevant section I have in my sshd_config: Match User root, Address 10.1.1.7 PermitRootLogin yes AllowTcpForwarding yes AllowAgentForwarding yes AuthorizedKeysFile /etc/ssh/dmz_keys ChrootDirectory none So, nothing suspicious, I think. I tried matching on various criteria, but sshd chokes every time. As soon as I remove the "Match" statement (and *only* the "Match" statement, leaving anything inside that block intact, i.e. active), then sshd runs happily without any issues. This is what I have configured openssh with: %define my_ssh_config /etc/ssh %define my_bin /usr/sbin %configure \ --host=armv6l-redhat-linux-uclibcgnueabi \ --bindir=%{my_bin} \ --sbindir=%{my_bin} \ --sysconfdir=%{my_ssh_config} \ --libexecdir=%{my_bin} \ --datadir=%{my_ssh_config} \ --with-tcp-wrappers \ --with-md5-passwords \ --with-default-path=/bin:/usr/bin:/usr/local/bin:/system/bin:/system/xbin \ --with-superuser-path=/sbin:/usr/sbin:/system/sbin:/bin:/usr/bin:/usr/local/bin:/system/bin:/system/xbin \ --with-privsep-path=/empty/sshd \ --with-pid-dir=%{my_ssh_config} \ --enable-vendor-patchlevel="FC-%{version}-%{release}" \ --disable-strip \ --without-zlib-version-check \ --with-ssl-engine \ --with-shadow \ --with-authorized-keys-command \ --disable-lastlog \ --with-ldflags=-static \ --without-rand-helper \ --without-smartcard \ --without-ldap \ --without-pam \ --without-selinux \ --without-audit \ --without-kerberos5 \ --without-libedit I've also disabled the privilege separation in sshd_config. Any ideas what might cause this segfault error I am getting? From nkadel at gmail.com Mon Mar 12 03:09:01 2012 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Sun, 11 Mar 2012 12:09:01 -0400 Subject: openssh static build - mission impossible? In-Reply-To: <4F5CC186.3020909@googlemail.com> References: <4F558EF0.3000308@googlemail.com> <20120306052826.30761.qmail@stuge.se> <4F55A3EE.6080506@googlemail.com> <20120306060004.945.qmail@stuge.se> <4F55CD7B.4030500@symas.com> <4F5CC186.3020909@googlemail.com> Message-ID: On Sun, Mar 11, 2012 at 11:15 AM, Mr Dash Four wrote: > > Sounds like he's been bitten by RedHat/Fedora's policy to replace all >> crypto on the system with MozillaNSS. You could easily dig up an unmodified >> glibc source to replace this. Also, the suggestion to use uClibc is still a >> better one. It will make static linking that much easier as well. >> > That was a very good suggestion as it turned out! > > What I did was to build a new toolchain for my target arch, based on > uclibc and then recompile the whole dependency tree, starting from zlib, > openssl etc. Quite a few tweaks and a few newly-discovered distro-specific > OpenSSH bugs later (which I'll report on bugzilla in the coming days) I > have brand new statically-linked openssh rpm packages (strictly speaking I > did not need openssh to be packaged in rpm, but I am so used to rpmbuild). > *OUCH*. As an admin who does quite a bit of RHEL support, I'll be fascinated to see your bug reports. Can you test the "ssh", "scp", "sftp", and "sshd" binaries separately and confirm whether they work well even connecting to other systems? > The size of the executables is indeed much smaller with uclibc - a simple > statically-linked "hello, world" application is just over 17k with uclibc, > while with glibc it was over 470k. > > As part of the "standard" build, there is hmac hash produced for the main > openssh executables and object files - I did not install these .hmac files > on the target device and from what I gather ssh(d) is not asking for them > or refusing to run, so what is the purpose of these? > > The newly-built sshd is running fine, though since I do not have shadow > passwords or any nss running on the target device, I had to "improvise" and > create these files manually so that ssh(d) could run - otherwise I was > getting a message saying ssh does not recognise me, asking me to "go away" > (ha!). > Interesting. I assume your /etc/shadow was created correctly? I've seen fascinating problems when someone manually put entries in /etc/passswd without matching entries in /etc/shadow. > > I am left with one very weird problem though: When I use a "Match" > statement, which matches on anything from "Address", "Host" or "User", sshd > chokes and exits with segfault error! Here is what I get after running sshd > with "-ddd": > > debug3: checking match for 'Address 10.1.1.7' user root host 10.1.1.7 addr > 10.1.1.7 > debug1: connection from 10.1.1.7 matched 'Address 10.1.1.7' at line 132 > debug3: match found > debug3: reprocess config:133 setting PermitRootLogin yes > debug3: reprocess config:134 setting AllowTcpForwarding yes > debug3: reprocess config:135 setting AllowAgentForwarding yes > debug3: reprocess config:136 setting AuthorizedKeysFile /etc/ssh/dmz_keys > debug3: reprocess config:137 setting ChrootDirectory none > /etc/rc.d/init.d/sshd: line 19: 5528 Segmentation fault $SSHD > $OPTIONS > > This is the relevant section I have in my sshd_config: > > Match User root, Address 10.1.1.7 > PermitRootLogin yes > AllowTcpForwarding yes > AllowAgentForwarding yes > AuthorizedKeysFile /etc/ssh/dmz_keys > ChrootDirectory none > > > So, nothing suspicious, I think. I tried matching on various criteria, but > sshd chokes every time. As soon as I remove the "Match" statement (and > *only* the "Match" statement, leaving anything inside that block intact, > i.e. active), then sshd runs happily without any issues. > > This is what I have configured openssh with: > > %define my_ssh_config /etc/ssh > %define my_bin /usr/sbin > %configure \ > --host=armv6l-redhat-linux-**uclibcgnueabi \ > --bindir=%{my_bin} \ > --sbindir=%{my_bin} \ > --sysconfdir=%{my_ssh_config} \ > --libexecdir=%{my_bin} \ > --datadir=%{my_ssh_config} \ > --with-tcp-wrappers \ > --with-md5-passwords \ > --with-default-path=/bin:/usr/**bin:/usr/local/bin:/system/**bin:/system/xbin > \ > --with-superuser-path=/sbin:/**usr/sbin:/system/sbin:/bin:/** > usr/bin:/usr/local/bin:/**system/bin:/system/xbin \ > --with-privsep-path=/empty/**sshd \ > --with-pid-dir=%{my_ssh_**config} \ > --enable-vendor-patchlevel="**FC-%{version}-%{release}" \ > --disable-strip \ > --without-zlib-version-check \ > --with-ssl-engine \ > --with-shadow \ > --with-authorized-keys-command \ > --disable-lastlog \ > --with-ldflags=-static \ > --without-rand-helper \ > --without-smartcard \ > --without-ldap \ > --without-pam \ > --without-selinux \ > --without-audit \ > --without-kerberos5 \ > --without-libedit > > I've also disabled the privilege separation in sshd_config. Any ideas what > might cause this segfault error I am getting? > Looks like time to run strace and non-daemon mode for sshd. Can you do those on the test environment? > ______________________________**_________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/**mailman/listinfo/openssh-unix-**dev > From mr.dash.four at googlemail.com Mon Mar 12 04:08:43 2012 From: mr.dash.four at googlemail.com (Mr Dash Four) Date: Sun, 11 Mar 2012 17:08:43 +0000 Subject: openssh static build - mission impossible? In-Reply-To: References: <4F558EF0.3000308@googlemail.com> <20120306052826.30761.qmail@stuge.se> <4F55A3EE.6080506@googlemail.com> <20120306060004.945.qmail@stuge.se> <4F55CD7B.4030500@symas.com> <4F5CC186.3020909@googlemail.com> Message-ID: <4F5CDC1B.7050006@googlemail.com> > What I did was to build a new toolchain for my target arch, based > on uclibc and then recompile the whole dependency tree, starting > from zlib, openssl etc. Quite a few tweaks and a few > newly-discovered distro-specific OpenSSH bugs later (which I'll > report on bugzilla in the coming days) I have brand new > statically-linked openssh rpm packages (strictly speaking I did > not need openssh to be packaged in rpm, but I am so used to rpmbuild). > > > *OUCH*. As an admin who does quite a bit of RHEL support, I'll be > fascinated to see your bug reports. I will be reporting them over the coming days - none of them are very serious, though quite annoying they are, and from what I remember they most come from the Fedora patches applied to the source tree (quite frustrating that was, since I was able to build a "vanilla" openssh at the first time of asking). > Can you test the "ssh", "scp", "sftp", and "sshd" binaries separately > and confirm whether they work well even connecting to other systems? So far I have tested all of those plus the keygen facilites, but except ssh - that will have to wait a bit until I get my other machine properly set up. > > The newly-built sshd is running fine, though since I do not have > shadow passwords or any nss running on the target device, I had to > "improvise" and create these files manually so that ssh(d) could > run - otherwise I was getting a message saying ssh does not > recognise me, asking me to "go away" (ha!). > > Interesting. I assume your /etc/shadow was created correctly? I've > seen fascinating problems when someone manually put entries in > /etc/passswd without matching entries in /etc/shadow. Nothing was created at all as my device do not use/have shadow or anything like that (etc/passwd, /etc/shadow, /etc/group, /etc/gshadow, /etc/shells and /etc/profile were all missing). I did something very similar to the following sequence of commands: echo "root:x:0:0::/usr/local/root_ssh_home:/system/xbin/bash" > /etc/passwd echo "root::14531:0:99999:7:::" > /etc/shadow echo "root:x:0:" > /etc/group echo "root:!::" > /etc/gshadow echo "/system/xbin/bash" > /etc/shells echo "PATH=\"/bin:/usr/bin:/usr/local/bin:/system/bin:/system/xbin\"" > /etc/profile echo "export PATH" >> /etc/profile I did *not* register password for root as I do not plan to login with passwords using ssh - only public keys, nothing else. Besides, I do not have passwd or useradd/usermod, groupadd/groupmod either. > I've also disabled the privilege separation in sshd_config. Any > ideas what might cause this segfault error I am getting? > > Looks like time to run strace and non-daemon mode for sshd. Can you do > those on the test environment? You mean on the device where sshd runs? I don't have strace there, so if I have to deploy and use it, I have to cross-compile it and static-build it first for the target arch :-\ The logs I posted previously were done when sshd runs in non-daemon mode (I run it as "OPTIONS=-ddd /etc/rc.d/init.d/sshd start" - that automatically starts sshd in non-daemon mode with the highest level of debugging available - level 3 with everything reported on the console). From alex at alemate.ru Mon Mar 12 05:57:03 2012 From: alex at alemate.ru (Alexander V Alekseev) Date: Sun, 11 Mar 2012 22:57:03 +0400 (MSK) Subject: [patch] Threading support in ssh-agent Message-ID: Hi all! I do not know openssh patch policy so I am just sending the patch to the mailing list. Sorry for inconvenience. Ssh-agent seems to be too slow if you need to access thousands of servers. This is a simple patch to enable threading in ssh2 authentication. Patch adds "-p numthreads" option and defaults to the number of processors. I've tested it as I could, but unfortunately I could check it only in Linux environment. Though it shouldn't break anything. Bye. Alex. -------------- next part -------------- Index: Makefile.in =================================================================== RCS file: /cvs/openssh/Makefile.in,v retrieving revision 1.325 diff -u -r1.325 Makefile.in --- Makefile.in 5 Aug 2011 20:15:18 -0000 1.325 +++ Makefile.in 11 Mar 2012 18:27:13 -0000 @@ -149,8 +149,8 @@ ssh-add$(EXEEXT): $(LIBCOMPAT) libssh.a ssh-add.o $(LD) -o $@ ssh-add.o $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS) -ssh-agent$(EXEEXT): $(LIBCOMPAT) libssh.a ssh-agent.o ssh-pkcs11-client.o - $(LD) -o $@ ssh-agent.o ssh-pkcs11-client.o $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS) +ssh-agent$(EXEEXT): $(LIBCOMPAT) libssh.a ssh-agent.o ssh-pkcs11-client.o ssh-openssl-thread-locking.o + $(LD) -o $@ ssh-agent.o ssh-pkcs11-client.o ssh-openssl-thread-locking.o $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS) ssh-keygen$(EXEEXT): $(LIBCOMPAT) libssh.a ssh-keygen.o $(LD) -o $@ ssh-keygen.o $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS) Index: configure.ac =================================================================== RCS file: /cvs/openssh/configure.ac,v retrieving revision 1.487 diff -u -r1.487 configure.ac --- configure.ac 23 Feb 2012 23:40:43 -0000 1.487 +++ configure.ac 11 Mar 2012 18:27:16 -0000 @@ -2440,6 +2440,83 @@ AC_MSG_ERROR([OpenSSH has no source of random numbers. Please configure OpenSSL with an entropy source or re-run configure using one of the --with-prngd-port or --with-prngd-socket options]) fi +AC_MSG_CHECKING([whether openssh has thread support compiled-in]) +AC_COMPILE_IFELSE([ + AC_LANG_PROGRAM( + [[ + #define OPENSSL_THREAD_DEFINES + #include + ]] , [[ + #if defined(OPENSSL_THREADS) + return 1; + #else + Must_not_compile 1 2 3; + #endif + ]] + ) + ] , [ + AC_MSG_RESULT([yes]) + have_openssl_threads=yes; + ] , [ + AC_MSG_RESULT([no - threading could not be used]) + ] +) + +AC_ARG_WITH([pthread], + [ --with-pthread Use pthread], + [ + if test "x$withval" = "xno" ; then + AC_MSG_CHECKING([whether pthread support enabled]) + AC_MSG_RESULT([no]) + ssh_agent_options="threading:no" + elif test "x$withval" = "xyes"; then + AC_CHECK_LIB(pthread, pthread_create,, + [ + AC_MSG_ERROR([pthread library not found]) + ] + ) + if test "$have_openssl_threads" ; then + true; + else + AC_MSG_ERROR([Openssl doesn't have thread support. Threading could not be used.]) + fi + + ssh_agent_options="threading:yes" + else + AC_MSG_ERROR([--with-pthread value must be 'yes' or 'no', but not '$withval']) + fi + ], + [ + AC_CHECK_LIB(pthread, pthread_create) + + if test "$ac_cv_lib_pthread_pthread_create" -a "$have_openssl_threads" ; then + ssh_agent_options="threading:yes" + fi + ] +) + +if test "x$ssh_agent_options" = "xthreading:yes" ; then + AC_MSG_CHECKING([sysconf(_SC_NPROCESSORS_CONF)]) + AC_COMPILE_IFELSE([ + AC_LANG_PROGRAM( + [[ + #include + ]] , [[ + sysconf(_SC_NPROCESSORS_CONF); + ]] + ) + ] , [ + AC_DEFINE([HAVE___SC_NPROCESSORS_CONF],[],[Whether sysconf(_SC_NPROCESSORS_CONF) is supported.]) + AC_MSG_RESULT([yes]) + ssh_agent_options="$ssh_agent_options nthreads:auto" + ] , [ + AC_MSG_RESULT([no]) + AC_MSG_WARN([ssh-agent: do not use threading by default]) + ssh_agent_options="$ssh_agent_options nthreads:manual,default=0" + ] + ) +fi + # Check for PAM libs PAM_MSG="no" AC_ARG_WITH([pam], @@ -4285,6 +4362,7 @@ echo " BSD Auth support: $BSD_AUTH_MSG" echo " Random number source: $RAND_MSG" echo " Privsep sandbox style: $SANDBOX_STYLE" +echo " ssh-agent: $ssh_agent_options" echo "" Index: ssh-agent.1 =================================================================== RCS file: /cvs/openssh/ssh-agent.1,v retrieving revision 1.53 diff -u -r1.53 ssh-agent.1 --- ssh-agent.1 1 Dec 2010 00:50:35 -0000 1.53 +++ ssh-agent.1 11 Mar 2012 18:27:16 -0000 @@ -102,6 +102,12 @@ .Xr ssh-add 1 overrides this value. Without this option the default maximum lifetime is forever. +.It Fl p Ar numthreads +Start given number of ssh2 auth threads. Defaults to number of processors if +.Pa sysconf(_SC_NPROCESSORS_CONF) +is supported by the environment or to 0. 0 means "single-threaded mode". + +This option is unavailable if threading is not compiled in. .El .Pp If a commandline is given, this is executed as a subprocess of the agent. Index: ssh-agent.c =================================================================== RCS file: /cvs/openssh/ssh-agent.c,v retrieving revision 1.194 diff -u -r1.194 ssh-agent.c --- ssh-agent.c 3 Jun 2011 04:14:16 -0000 1.194 +++ ssh-agent.c 11 Mar 2012 18:27:17 -0000 @@ -13,6 +13,8 @@ * * Copyright (c) 2000, 2001 Markus Friedl. All rights reserved. * + * Threading support by Alexander Alekseev + * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: @@ -58,6 +60,9 @@ #ifdef HAVE_PATHS_H # include #endif +#ifdef HAVE_LIBPTHREAD +#include "ssh-openssl-thread-locking.h" +#endif #include #include #include @@ -88,6 +93,9 @@ AUTH_UNUSED, AUTH_SOCKET, AUTH_CONNECTION +#ifdef HAVE_LIBPTHREAD + , AUTH_INUSE +#endif } sock_type; typedef struct { @@ -137,6 +145,50 @@ /* Default lifetime (0 == forever) */ static int lifetime = 0; +#ifdef HAVE_LIBPTHREAD + +#define MAX_THREADS 20 + +#define REQ_QUEUE_LEN (MAX_THREADS * 2) + +typedef void (*AuthWorker)(SocketEntry*); + +struct AuthRequestQueueEntry { + AuthWorker worker; + SocketEntry *e; +}; + +struct AuthRequestQueue { + struct AuthRequestQueueEntry queue[REQ_QUEUE_LEN]; + int first; + int used; + int inprogress; /* operated by get() */ + pthread_mutex_t lock; + pthread_cond_t cond; +}; + +struct Thread { + pthread_t tid; + pthread_mutex_t lock; /* is locked while thread is serving request. Used as barrier. */ + struct AuthRequestQueue* queue; +}; + +struct TPool { + struct Thread threads[MAX_THREADS]; + size_t num_threads; + struct AuthRequestQueue queue; +}; + +struct TPool tpool; + +void tpool_barrier(struct TPool*); + +#else + +#define tpool_barrier(a) do {} while(0) + +#endif + static void close_socket(SocketEntry *e) { @@ -154,7 +206,7 @@ int i; for (i = 0; i <=2; i++) { - TAILQ_INIT(&idtable[i].idlist); + TAILQ_INIT(&(idtable[i].idlist)); idtable[i].nentries = 0; } } @@ -355,6 +407,224 @@ datafellows = odatafellows; } +#ifdef HAVE_LIBPTHREAD + +int +req_queue_init(struct AuthRequestQueue* q, int inprogress_initial) +{ + memset(q, 0, sizeof(struct AuthRequestQueue)); + + if (pthread_mutex_init(&(q->lock), 0)) { + error("pthread_mutex_init(queue): %s", strerror(errno)); + return -1; + } + if (pthread_cond_init(&(q->cond), 0)) { + error("pthread_cond_init(queue): %s", strerror(errno)); + return -1; + } + q->inprogress = inprogress_initial; + return 0; +} + +int +req_queue_enqueue(struct AuthRequestQueue* q, AuthWorker worker, SocketEntry *e) +{ + int off; + + pthread_mutex_lock(&(q->lock)); + + while (q->used >= REQ_QUEUE_LEN) { + if (pthread_cond_wait(&(q->cond), &(q->lock))) { + error("pthread_cond_wait(enqueue): %s", strerror(errno)); + pthread_mutex_unlock(&(q->lock)); + return -1; + } + } + off = q->first + q->used; + if (off >= REQ_QUEUE_LEN) { + off -= REQ_QUEUE_LEN; + } + q->queue[off].worker = worker; + q->queue[off].e = e; + + if (q->used == 0) { + if (pthread_cond_signal(&(q->cond))) { + error("pthread_cond_signal(enqueue): %s", strerror(errno)); + } + } + q->used++; + pthread_mutex_unlock(&(q->lock)); + return 0; +} + +void thread_lock(struct Thread* t); +void thread_unlock(struct Thread* t); + +int +req_queue_unlock_thread_get_and_lock_thread(struct Thread* t, AuthWorker* out_worker, SocketEntry** out_e) +{ + + struct AuthRequestQueue* q = t->queue; + + pthread_mutex_lock(&(q->lock)); + thread_unlock(t); + + if (q->inprogress > 0) { + q->inprogress--; + } + + while (q->used <= 0) { + if (pthread_cond_wait(&(q->cond), &(q->lock))) { + error("pthread_cond_wait(get): %s", strerror(errno)); + thread_lock(t); + pthread_mutex_unlock(&(q->lock)); + return -1; + } + } + *out_worker = q->queue[q->first].worker; + *out_e = q->queue[q->first].e; + + q->first++; + + if (q->first >= REQ_QUEUE_LEN) { + q->first = 0; + } + + if (q->used >= REQ_QUEUE_LEN) { + if (pthread_cond_signal(&(q->cond))) { + error("pthread_cond_signal(get): %s", strerror(errno)); + } + } + q->used--; + q->inprogress++; + + thread_lock(t); + pthread_mutex_unlock(&(q->lock)); + return 0; +} + +/* Returns number of threads currently working plus number of requests in queue + * Returns -1 on error. */ +int +req_queue_still_unserved(struct AuthRequestQueue* q) +{ + int retval; + if (pthread_mutex_lock(&(q->lock))) { + error("pthread_mutex_lock(queue): %s", strerror(errno)); + return -1; + } + retval = q->inprogress + q->used; + pthread_mutex_unlock(&(q->lock)); + return retval; +} + +void* +auth_thread_run(struct Thread* t) +{ + SocketEntry* e; + AuthWorker worker; + + thread_lock(t); + while(1) { + if (req_queue_unlock_thread_get_and_lock_thread(t, &worker, &e)) { + sleep(1); + } else { + worker(e); + if (e->type == AUTH_INUSE) { + e->type = AUTH_CONNECTION; + } + } + } + return NULL; +} + +int +thread_init(struct Thread* t) +{ + if (pthread_mutex_init(&(t->lock), 0)) { + error("pthread_mutex_init(thread): %s", strerror(errno)); + return -1; + } + return 0; +} + +void +thread_lock(struct Thread* t) +{ + while (pthread_mutex_lock(&(t->lock))) { + if (errno != EINTR) { + error("pthread_mutex_lock(thread): %s", strerror(errno)); + sleep(1); + } + } +} + +void +thread_unlock(struct Thread* t) +{ + pthread_mutex_unlock(&(t->lock)); +} + +void tpool_barrier(struct TPool* p) +{ + size_t i; + + debug("tpool_barrier called"); + for(i = 0; i < p->num_threads; ++i) { + thread_lock(&(p->threads[i])); + thread_unlock(&(p->threads[i])); + } +} + +typedef void* (*PThreadThreadFunction)(void*); +int +tpool_init(struct TPool* p, int numthreads) +{ + int i; + + memset(p, 0, sizeof(struct TPool)); + + if (req_queue_init(&(p->queue), numthreads)) { + return -1; + } + + if (numthreads > MAX_THREADS) { + numthreads = MAX_THREADS; + } + for(i = 0; i < numthreads; i++) { + struct Thread* thr = &(p->threads[i]); + if (thread_init(thr)) { + return -1; + } + thr->queue = &(p->queue); + if (pthread_create(&(thr->tid), 0, (PThreadThreadFunction)auth_thread_run, thr)) { + error("pthread_create: %s", strerror(errno)); + return -1; + } + } + p->num_threads = numthreads; + + openssl_thread_locks_setup(); + return 0; +} + +#endif + +static void +schedule_sign_request2(SocketEntry *e) +{ +#ifndef HAVE_LIBPTHREAD + process_sign_request2(e); +#else + if (tpool.num_threads) { + e->type = AUTH_INUSE; + req_queue_enqueue(&(tpool.queue), process_sign_request2, e); + } else { + process_sign_request2(e); + } +#endif +} + /* shared */ static void process_remove_identity(SocketEntry *e, int version) @@ -397,8 +667,11 @@ "internal error: tab->nentries %d", tab->nentries); TAILQ_REMOVE(&tab->idlist, id, next); - free_identity(id); tab->nentries--; + + tpool_barrier(&tpool); + + free_identity(id); success = 1; } key_free(key); @@ -418,6 +691,10 @@ for (id = TAILQ_FIRST(&tab->idlist); id; id = TAILQ_FIRST(&tab->idlist)) { TAILQ_REMOVE(&tab->idlist, id, next); + tab->nentries--; + + tpool_barrier(&tpool); + free_identity(id); } @@ -447,8 +724,11 @@ if (now >= id->death) { debug("expiring key '%s'", id->comment); TAILQ_REMOVE(&tab->idlist, id, next); - free_identity(id); tab->nentries--; + + tpool_barrier(&tpool); + + free_identity(id); } else deadline = (deadline == 0) ? id->death : MIN(deadline, id->death); @@ -776,8 +1056,11 @@ nxt = TAILQ_NEXT(id, next); if (!strcmp(provider, id->provider)) { TAILQ_REMOVE(&tab->idlist, id, next); - free_identity(id); tab->nentries--; + + tpool_barrier(&tpool); + + free_identity(id); } } } @@ -861,7 +1144,7 @@ break; /* ssh2 */ case SSH2_AGENTC_SIGN_REQUEST: - process_sign_request2(e); + schedule_sign_request2(e); break; case SSH2_AGENTC_REQUEST_IDENTITIES: process_request_identities(e, 2); @@ -943,6 +1226,10 @@ break; case AUTH_UNUSED: break; +#ifdef HAVE_LIBPTHREAD + case AUTH_INUSE: + break; +#endif default: fatal("Unknown socket type %d", sockets[i].type); break; @@ -981,6 +1268,13 @@ if (parent_alive_interval != 0) deadline = (deadline == 0) ? parent_alive_interval : MIN(deadline, parent_alive_interval); +#ifdef HAVE_LIBPTHREAD + if (req_queue_still_unserved(&(tpool.queue))) { + tv.tv_sec = 0; + tv.tv_usec = 10000; /* 1/100 of a second */ + *tvpp = &tv; + } else +#endif if (deadline == 0) { *tvpp = NULL; } else { @@ -1062,6 +1356,10 @@ process_message(&sockets[i]); } break; +#ifdef HAVE_LIBPTHREAD + case AUTH_INUSE: + break; +#endif default: fatal("Unknown type %d", sockets[i].type); } @@ -1120,6 +1418,9 @@ fprintf(stderr, " -d Debug mode.\n"); fprintf(stderr, " -a socket Bind agent socket to given name.\n"); fprintf(stderr, " -t life Default identity lifetime (seconds).\n"); +#ifdef HAVE_LIBPTHREAD + fprintf(stderr, " -p numthr Number of authenticate threads. 0 - do not use separate threads.\n"); +#endif exit(1); } @@ -1142,6 +1443,9 @@ char pidstrbuf[1 + 3 * sizeof pid]; struct timeval *tvp = NULL; size_t len; +#ifdef HAVE_LIBPTHREAD + int numthreads = -1; +#endif /* Ensure that fds 0, 1 and 2 are open or directed to /dev/null */ sanitise_stdfd(); @@ -1160,7 +1464,7 @@ __progname = ssh_get_progname(av[0]); seed_rng(); - while ((ch = getopt(ac, av, "cdksa:t:")) != -1) { + while ((ch = getopt(ac, av, "cdksa:t:p:")) != -1) { switch (ch) { case 'c': if (s_flag) @@ -1189,6 +1493,22 @@ usage(); } break; + case 'p': +#ifdef HAVE_LIBPTHREAD + numthreads = atoi(optarg); + if ((numthreads <= 0) && strcmp(optarg, "0")) { + fprintf(stderr, "Invalid numthreads\n"); + usage(); + } + if (numthreads > MAX_THREADS) { + fprintf(stderr, "Number of threads is limited to %u. Recompile to increase.\n", MAX_THREADS); + usage(); + } +#else + fprintf(stderr, "Threading support not compiled in. \"-p numthreads\" not supported.\n"); + usage(); +#endif + break; default: usage(); } @@ -1355,6 +1675,27 @@ signal(SIGTERM, cleanup_handler); nalloc = 0; +#ifdef HAVE_LIBPTHREAD + if (numthreads == -1) { +#ifdef HAVE___SC_NPROCESSORS_CONF + numthreads = sysconf(_SC_NPROCESSORS_CONF); + if (numthreads == -1) { + error("sysconf(_SC_NPROCESSORS_CONF): %s", strerror(errno)); + error("Defaults to single-thread mode."); + numthreads = 0; + } else if (numthreads == 1) { + numthreads = 0; + } +#else + numthreads = 0; /* Single thread. */ +#endif /* HAVE___SC_NPROCESSORS_CONF */ + } + + if (tpool_init(&tpool, numthreads)) { + error("Failed to init threads pool."); + cleanup_exit(1); + } +#endif while (1) { prepare_select(&readsetp, &writesetp, &max_fd, &nalloc, &tvp); result = select(max_fd + 1, readsetp, writesetp, NULL, tvp); --- ssh-openssl-thread-locking.c 2012-03-11 00:00:00.000000000 +0000 +++ ssh-openssl-thread-locking.c 2012-03-11 21:37:10.000000000 +0400 @@ -0,0 +1,132 @@ +/* This code is taken from openssl distribution crypto/threads/mttest.c */ +/* Non-pthreads code is removed. */ +/* */ +/* */ +/* */ +/* Copyright (C) 1995-1998 Eric Young (eay at cryptsoft.com) + * All rights reserved. + * + * This package is an SSL implementation written + * by Eric Young (eay at cryptsoft.com). + * The implementation was written so as to conform with Netscapes SSL. + * + * This library is free for commercial and non-commercial use as long as + * the following conditions are aheared to. The following conditions + * apply to all code found in this distribution, be it the RC4, RSA, + * lhash, DES, etc., code; not just the SSL code. The SSL documentation + * included with this distribution is covered by the same copyright terms + * except that the holder is Tim Hudson (tjh at cryptsoft.com). + * + * Copyright remains Eric Young's, and as such any Copyright notices in + * the code are not to be removed. + * If this package is used in a product, Eric Young should be given attribution + * as the author of the parts of the library used. + * This can be in the form of a textual message at program startup or + * in documentation (online or textual) provided with the package. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * 3. All advertising materials mentioning features or use of this software + * must display the following acknowledgement: + * "This product includes cryptographic software written by + * Eric Young (eay at cryptsoft.com)" + * The word 'cryptographic' can be left out if the rouines from the library + * being used are not cryptographic related :-). + * 4. If you include any Windows specific code (or a derivative thereof) from + * the apps directory (application code) you must include an acknowledgement: + * "This product includes software written by Tim Hudson (tjh at cryptsoft.com)" + * + * THIS SOFTWARE IS PROVIDED BY ERIC YOUNG ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + * The licence and distribution terms for any publically available version or + * derivative of this code cannot be changed. i.e. this code cannot simply be + * copied and put under another distribution licence + * [including the GNU Public Licence.] + */ + +#include "includes.h" + +#include "ssh-openssl-thread-locking.h" + +#include + +#include +#include +#include + +#ifdef HAVE_LIBPTHREAD + +static pthread_mutex_t *lock_cs; +static long *lock_count; + +void pthreads_locking_callback(int mode, int type, char *file, int line); +unsigned long pthreads_thread_id(void); + +void openssl_thread_locks_setup(void) + { + int i; + + lock_cs=OPENSSL_malloc(CRYPTO_num_locks() * sizeof(pthread_mutex_t)); + lock_count=OPENSSL_malloc(CRYPTO_num_locks() * sizeof(long)); + for (i=0; i + +#ifdef HAVE_LIBPTHREAD + +void openssl_thread_locks_setup(void); +void openssl_thread_locks_cleanup(void); + +#endif + +#endif From keisial at gmail.com Mon Mar 12 07:31:12 2012 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Sun, 11 Mar 2012 21:31:12 +0100 Subject: [patch] Threading support in ssh-agent In-Reply-To: References: Message-ID: <4F5D0B90.1090200@gmail.com> On 11/03/12 19:57, Alexander V Alekseev wrote: > Hi all! > > I do not know openssh patch policy so I am just sending > the patch to the mailing list. Sorry for inconvenience. > Ssh-agent seems to be too slow if you need to access thousands of > servers. This is a simple patch to enable threading in ssh2 > authentication. > Patch adds "-p numthreads" option and defaults to the number of > processors. > > I've tested it as I could, but unfortunately I could check it > only in Linux environment. Though it shouldn't break anything. > > Bye. Alex. You concurrently access thousands of servers? O_O What's your use case? How does your threaded ssh-agent work with keys requiring confirmation? Would the user be flooded with a SSH_ASKPASS instance per thread? From alex at alemate.ru Mon Mar 12 08:53:59 2012 From: alex at alemate.ru (alex at alemate.ru) Date: Mon, 12 Mar 2012 01:53:59 +0400 (MSK) Subject: [patch] Threading support in ssh-agent In-Reply-To: <4F5D0B90.1090200@gmail.com> References: <4F5D0B90.1090200@gmail.com> Message-ID: On Sun, 11 Mar 2012, ?ngel Gonz?lez wrote: > On 11/03/12 19:57, Alexander V Alekseev wrote: >> Hi all! >> >> I do not know openssh patch policy so I am just sending >> the patch to the mailing list. Sorry for inconvenience. >> Ssh-agent seems to be too slow if you need to access thousands of >> servers. This is a simple patch to enable threading in ssh2 >> authentication. >> Patch adds "-p numthreads" option and defaults to the number of >> processors. >> >> I've tested it as I could, but unfortunately I could check it >> only in Linux environment. Though it shouldn't break anything. >> >> Bye. Alex. > You concurrently access thousands of servers? O_O What's your use case? Large server farm. Todays web services usually require some ;-) > How does your threaded ssh-agent work with keys requiring confirmation? > Would the user be flooded with a SSH_ASKPASS instance per thread? We do not use it. From nkadel at gmail.com Mon Mar 12 09:14:03 2012 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Sun, 11 Mar 2012 18:14:03 -0400 Subject: [patch] Threading support in ssh-agent In-Reply-To: <4F5D0B90.1090200@gmail.com> References: <4F5D0B90.1090200@gmail.com> Message-ID: 2012/3/11 ?ngel Gonz?lez > On 11/03/12 19:57, Alexander V Alekseev wrote: > > Hi all! > > > > I do not know openssh patch policy so I am just sending > > the patch to the mailing list. Sorry for inconvenience. > > Ssh-agent seems to be too slow if you need to access thousands of > > servers. This is a simple patch to enable threading in ssh2 > > authentication. > > Patch adds "-p numthreads" option and defaults to the number of > > processors. > > > > I've tested it as I could, but unfortunately I could check it > > only in Linux environment. Though it shouldn't break anything. > > > > Bye. Alex. > > You concurrently access thousands of servers? O_O What's your use case? > How does your threaded ssh-agent work with keys requiring confirmation? > Would the user be flooded with a SSH_ASKPASS instance per thread? > > I can think of several. Scripting of network wide surveys, rsnapshot over large environments, and Nagios over ssh plugins leap to mind. From jamie.beverly at yahoo.com Mon Mar 12 09:41:48 2012 From: jamie.beverly at yahoo.com (Jamie Beverly) Date: Sun, 11 Mar 2012 15:41:48 -0700 (PDT) Subject: [patch] Threading support in ssh-agent In-Reply-To: References: <4F5D0B90.1090200@gmail.com> Message-ID: <1331505708.68473.YahooMailNeo@web31804.mail.mud.yahoo.com> ----- Original Message ----- > From: Nico Kadel-Garcia > To: ?ngel Gonz?lez > Cc: Alexander V Alekseev ; openssh-unix-dev at mindrot.org > Sent: Sunday, March 11, 2012 3:14 PM > Subject: Re: [patch] Threading support in ssh-agent > > 2012/3/11 ?ngel Gonz?lez > >> On 11/03/12 19:57, Alexander V Alekseev wrote: >> >? ? ? ? Hi all! >> > >> >? ? I do not know openssh patch policy so I am just sending >> > the patch to the mailing list. Sorry for inconvenience. >> >? ? Ssh-agent seems to be too slow if you need to access thousands of >> > servers. This is a simple patch to enable threading in ssh2 >> > authentication. >> > Patch adds "-p numthreads" option and defaults to the number > of >> > processors. >> > >> >? ? I've tested it as I could, but unfortunately I could check it >> > only in Linux environment. Though it shouldn't break anything. >> > >> >? ? ? ? Bye. Alex. >> >> You concurrently access thousands of servers? O_O What's your use case? >> How does your threaded ssh-agent work with keys requiring confirmation? >> Would the user be flooded with a SSH_ASKPASS instance per thread? >> >> > I can think of several. Scripting of network wide surveys, rsnapshot over > large environments, and Nagios over? ssh plugins leap to mind. I haven't looked over the patch, but I can confirm the real-world use-case for using ssh-agent for authentication on thousands of hosts concurrently. I regularly ssh to several thousand hosts (several times a day on most days) for various reasons. Many uses are just to execute a single command on thousands of hosts in parallel and aggregate the output, other uses are as above. Up until now, I've just had my scripts automatically partition the work between multiple agents, usually with about 100-300 concurrent jobs per agent. Of course this means entering the password for the keys for multiple agents, which is an annoyance at after reboots. I would wager this is a similar for others in the LSPE space. So, while I can't speak to the patch, I can at least confirm the existance of the usecase. From john.m.olsson at ericsson.com Mon Mar 12 22:47:18 2012 From: john.m.olsson at ericsson.com (John Olsson M) Date: Mon, 12 Mar 2012 12:47:18 +0100 Subject: OpenSSH support for X.509 certificates? Message-ID: Hi, I was looking for X.509 certificate support in OpenSSH and found bug #958 https://bugzilla.mindrot.org/show_bug.cgi?id=958 This patch has been maintained outside of main trunk since 2004. Stupid question: What is the reason for it not being accepted into the main trunk? /John From abeltomillo at gmail.com Tue Mar 13 05:26:14 2012 From: abeltomillo at gmail.com (Abel Romero) Date: Mon, 12 Mar 2012 19:26:14 +0100 Subject: ssh shell spawn Message-ID: Hello, I'm trying to add a feature to the ssh daemon. It consists in log all the buffer session between client and server side into a log file. I've coded a shell that works with pipes, it opens 2 fds for each std (you can see code at the end) and so the communication can be transferred to the client end point, the server side and to the log file. My goal is to patch it into ssh, but for that I need to locate where the ssh dups (with dup2() the 0,1 and 2 fds with the client socket fd (I guess it does like this, I've no another idea without pipes, but I've read do_exec() and nothing about pipes, so... how can it be possible if not like this way?) for the best working of the application. Basically I want to know where can I putt the code below. Thanks in advance. The code of the mini shell daemon with buffer session log is which follows (I tried to simulate pty ssh features): #include #include #include int main (void) { ? int fd_s = socket (AF_INET, SOCK_STREAM, IPPROTO_IP); ? struct sockaddr_in info_s = {.sin_family = AF_INET,.sin_port = ? ? ? htons (1024),.sin_zero = {0, 0, 0, 0, 0, 0, 0},.sin_addr.s_addr = 0 ? }; ? bind (fd_s, &info_s, sizeof (info_s)); ? listen (fd_s, 1); ? int info_s_len = sizeof (struct sockaddr_in); ? int fd_c; ? struct sockaddr_in info_c; ? while ((fd_c = accept (fd_s, &info_c, &info_s_len))) ? ? { ? ? ? printf ("client connected.\n"); ? ? ? if (!fork ()) ? ? { ? ? ? int fd = open ("log", O_WRONLY | O_CREAT | O_APPEND); ? ? ? int pty, tty; ? ? ? char *name; ? ? ? openpty (&pty, &tty, NULL, NULL, NULL); ? ? ? name = ttyname (tty); ? ? ? int p0[2], p1[2], p2[2]; ? ? ? pipe (p0); ? ? ? pipe2 (p1, O_NONBLOCK); ? ? ? pipe2 (p2, O_NONBLOCK); ? ? ? dup2 (tty, 0); ? ? ? dup2 (tty, 1); ? ? ? dup2 (tty, 2); ? ? ? dup2 (p0[0], 0); ? ? ? dup2 (p1[1], 1); ? ? ? dup2 (p2[1], 2); ? ? ? if (!fork ()) ? ? ? ? { ? ? ? ? ? system ("/bin/sh"); ? ? ? ? ? close (p0[0]); ? ? ? ? ? close (p0[1]); ? ? ? ? ? close (p1[0]); ? ? ? ? ? close (p1[1]); ? ? ? ? ? close (p2[0]); ? ? ? ? ? close (p2[1]); ? ? ? ? ? close (fd_c); ? ? ? ? ? close (fd); ? ? ? ? ? // some log ? ? ? ? ? exit (0); ? ? ? ? } ? ? ? else ? ? ? ? { ? ? ? ? ? fd_set rd, wr; ? ? ? ? ? fcntl (fd_c, F_SETFL, O_NONBLOCK); ? ? ? ? ? FD_ZERO (&rd); ? ? ? ? ? FD_ZERO (&wr); ? ? ? ? ? FD_SET (p1[0], &rd); ? ? ? ? ? FD_SET (p2[0], &rd); ? ? ? ? ? FD_SET (fd_c, &rd); ? ? ? ? ? char *b = 0; ? ? ? ? ? int bl, i; ? ? ? ? ? while (select (p2[1] + 1, &rd, &wr, 0, 0)) ? ? ? ? { ? ? ? ? ? char c; ? ? ? ? ? if (FD_ISSET (fd_c, &rd)) ? ? ? ? ? ? { ? ? ? ? ? ? ? for (i = bl = b = 0; 1; i++) ? ? ? ? ? ? { ? ? ? ? ? ? ? char c; ? ? ? ? ? ? ? int ret = recv (fd_c, &c, sizeof (c), 0); ? ? ? ? ? ? ? if (ret == sizeof (c)) ? ? ? ? ? ? ? ? { ? ? ? ? ? ? ? ? ? bl += sizeof (char); ? ? ? ? ? ? ? ? ? b = realloc (b, bl); ? ? ? ? ? ? ? ? ? b[i] = c; ? ? ? ? ? ? ? ? } ? ? ? ? ? ? ? else if (ret == 0) ? ? ? ? ? ? ? ? { ? ? ? ? ? ? ? ? ? close (fd_c); ? ? ? ? ? ? ? ? ? free (b); ? ? ? ? ? ? ? ? ? exit (0); ? ? ? ? ? ? ? ? } ? ? ? ? ? ? ? else if (ret == -1) ? ? ? ? ? ? ? ? { ? ? ? ? ? ? ? ? ? write (p0[1], b, bl); ? ? ? ? ? ? ? ? ? write (fd, b, bl); ? ? ? ? ? ? ? ? ? free (b); ? ? ? ? ? ? ? ? ? break; ? ? ? ? ? ? ? ? } ? ? ? ? ? ? } ? ? ? ? ? ? } ? ? ? ? ? else if (FD_ISSET (p1[0], &rd)) ? ? ? ? ? ? { ? ? ? ? ? ? ? for (i = bl = b = 0; 1; i++) ? ? ? ? ? ? { ? ? ? ? ? ? ? char c; ? ? ? ? ? ? ? int ret = read (p1[0], &c, sizeof (c)); ? ? ? ? ? ? ? if (ret == sizeof (c)) ? ? ? ? ? ? ? ? { ? ? ? ? ? ? ? ? ? bl += sizeof (c); ? ? ? ? ? ? ? ? ? b = realloc (b, bl); ? ? ? ? ? ? ? ? ? b[i] = c; ? ? ? ? ? ? ? ? } ? ? ? ? ? ? ? else if (ret == -1) ? ? ? ? ? ? ? ? { ? ? ? ? ? ? ? ? ? send (fd_c, b, bl, 0); ? ? ? ? ? ? ? ? ? write (fd, b, bl); ? ? ? ? ? ? ? ? ? free (b); ? ? ? ? ? ? ? ? ? break; ? ? ? ? ? ? ? ? } ? ? ? ? ? ? ? else ? ? ? ? ? ? ? ? { ? ? ? ? ? ? ? ? } ? ? ? ? ? ? } ? ? ? ? ? ? } ? ? ? ? ? else if (FD_ISSET (p2[0], &rd)) ? ? ? ? ? ? { ? ? ? ? ? ? ? for (i = bl = b = 0; 1; i++) ? ? ? ? ? ? { ? ? ? ? ? ? ? char c; ? ? ? ? ? ? ? int ret = read (p2[0], &c, sizeof (c)); ? ? ? ? ? ? ? if (ret == sizeof (c)) ? ? ? ? ? ? ? ? { ? ? ? ? ? ? ? ? ? bl += sizeof (c); ? ? ? ? ? ? ? ? ? b = realloc (b, bl); ? ? ? ? ? ? ? ? ? b[i] = c; ? ? ? ? ? ? ? ? } ? ? ? ? ? ? ? else if (ret == -1) ? ? ? ? ? ? ? ? { ? ? ? ? ? ? ? ? ? send (fd_c, b, bl, 0); ? ? ? ? ? ? ? ? ? write (fd, b, bl); ? ? ? ? ? ? ? ? ? free (b); ? ? ? ? ? ? ? ? ? break; ? ? ? ? ? ? ? ? } ? ? ? ? ? ? } ? ? ? ? ? ? } ? ? ? ? ? FD_ZERO (&rd); ? ? ? ? ? FD_ZERO (&wr); ? ? ? ? ? FD_SET (p1[0], &rd); ? ? ? ? ? FD_SET (p2[0], &rd); ? ? ? ? ? FD_SET (fd_c, &rd); ? ? ? ? } ? ? ? ? } ? ? } ? ? } ? return 0; } From mr.dash.four at googlemail.com Tue Mar 13 13:11:58 2012 From: mr.dash.four at googlemail.com (Mr Dash Four) Date: Tue, 13 Mar 2012 02:11:58 +0000 Subject: openssh static build - mission impossible? In-Reply-To: References: <4F558EF0.3000308@googlemail.com> <20120306052826.30761.qmail@stuge.se> <4F55A3EE.6080506@googlemail.com> <20120306060004.945.qmail@stuge.se> <4F55CD7B.4030500@symas.com> <4F5CC186.3020909@googlemail.com> Message-ID: <4F5EACEE.9050909@googlemail.com> > Looks like time to run strace and non-daemon mode for sshd. Can you do > those on the test environment? OK, I managed to smuggle in strace (don't ask!) and ran it with "strace -ffvrTxo sshd /etc/rc.d/init.d/sshd start". As a result of this, I've got something very interesting - in the process that subsequently segfaults, which is span by the main sshd executable, at the end of the trace I get this little gem: ----->8----------- 0.000732 bind(4, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 0 <0.000152> 0.000915 getsockname(4, {sa_family=AF_NETLINK, pid=2576, groups=00000000}, [12]) = 0 <0.000153> 0.002869 gettimeofday({1331602612, 171594}, NULL) = 0 <0.000153> 0.001038 recv(4, "\x14\x00\x00\x00\x12\x00\x01\x03\xb4\xa4\x5e\x4f\x00\x00\x00\x00\x00\x00\x00\x00", 20, 0) = 20 <0.000367> 0.001343 recvmsg(4, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"\xac\x01\x00\x00\x10\x00\x02\x00\xb4\xa4\x5e\x4f\x10\x0a\x00\x00\x00\x00\x04\x03\x01\x00\x00\x00\x49\x00\x01\x00\x00\x00\x00\x00"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 3492 <0.000305> 0.002380 recvmsg(4, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"\xb8\x01\x00\x00\x10\x00\x02\x00\xb4\xa4\x5e\x4f\x10\x0a\x00\x00\x00\x00\x01\x00\x09\x00\x00\x00\x02\x10\x00\x00\x00\x00\x00\x00"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 876 <0.000213> 0.002228 recvmsg(4, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"\x14\x00\x00\x00\x03\x00\x02\x00\xb4\xa4\x5e\x4f\x10\x0a\x00\x00\x00\x00\x00\x00\x09\x00\x00\x00\x02\x10\x00\x00\x00\x00\x00\x00"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 20 <0.000183> 0.002166 recv(4, "\x14\x00\x00\x00\x16\x00\x01\x03\xb5\xa4\x5e\x4f\x00\x00\x00\x00\x00\x00\x00\x00", 20, 0) = 20 <0.000275> 0.001282 recvmsg(4, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"\x30\x00\x00\x00\x14\x00\x02\x00\xb5\xa4\x5e\x4f\x10\x0a\x00\x00\x02\x08\x80\xfe\x01\x00\x00\x00\x08\x00\x01\x00\x7f\x00\x00\x01"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 108 <0.000244> 0.002625 recvmsg(4, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"\x14\x00\x00\x00\x03\x00\x02\x00\xb5\xa4\x5e\x4f\x10\x0a\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\x08\x00\x01\x00\x7f\x00\x00\x01"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 20 <0.000183> 0.002288 close(4) = 0 <0.000275> 0.001008 getuid32() = 0 <0.000153> 0.000763 --- SIGSEGV (Segmentation fault) @ 0 (1237ac) --- ------8<---------- So, it seems the offending function is our old friend getuid32()! Any suggestions? I have the full trace of everything (5 child processes were span in total and the one above was created when I tried to log in). From peter at stuge.se Tue Mar 13 13:49:46 2012 From: peter at stuge.se (Peter Stuge) Date: Tue, 13 Mar 2012 03:49:46 +0100 Subject: openssh static build - mission impossible? In-Reply-To: <4F5EACEE.9050909@googlemail.com> <4F5CC186.3020909@googlemail.com> References: <4F55CD7B.4030500@symas.com> <4F5CC186.3020909@googlemail.com> <4F5EACEE.9050909@googlemail.com> <4F558EF0.3000308@googlemail.com> <20120306052826.30761.qmail@stuge.se> <4F55A3EE.6080506@googlemail.com> <20120306060004.945.qmail@stuge.se> <4F55CD7B.4030500@symas.com> <4F5CC186.3020909@googlemail.com> Message-ID: <20120313024946.13869.qmail@stuge.se> Mr Dash Four wrote: > What I did was to build a new toolchain for my target arch, While a good idea per se, as per the original requirements you stated it is completely overkill. CFLAGS=-Dcrypt=DES_crypt would have been sufficient, as you could note from earlier emails. > I am left with one very weird problem though: When I use a "Match" > statement, which matches on anything from "Address", "Host" or > "User", sshd chokes and exits with segfault error! I guess those need the nsswitch functionality which you were sure that you wouldn't need, back when you were getting warnings about linking statically against glibc. Maybe you discovered this. uclibc is not glibc, so things may be different there. > Any ideas what might cause this segfault error I am getting? Not really. Sprinkle printfs across sshd where it is crashing. Mr Dash Four wrote: > "strace -ffvrTxo sshd /etc/rc.d/init.d/sshd start" It will not make any difference in this case, but I recommend doing away with all irrelevant unknowns when debugging, so better run /usr/sbin/sshd -ddd instead of that rc script. > 0.002288 close(4) = 0 <0.000275> > 0.001008 getuid32() = 0 <0.000153> > 0.000763 --- SIGSEGV (Segmentation fault) @ 0 (1237ac) --- > ------8<---------- > > So, it seems the offending function is our old friend getuid32()! No, not at all. getuid32() is shown to complete without error and after that some code in sshd uses a bad pointer and crashes. > Any suggestions? Ideally build sshd with debugging and run it in gdb and get a stack trace. If you don't want to get or make a suitable gdb then sprinkle printf() over sshd to find the crash and then the cause. //Peter From djm at mindrot.org Tue Mar 13 14:42:17 2012 From: djm at mindrot.org (Damien Miller) Date: Tue, 13 Mar 2012 14:42:17 +1100 (EST) Subject: Call for testing: OpenSSH-6.0 In-Reply-To: <86aa3qypb3.fsf@ds4.des.no> References: <868vjxbkkd.fsf@ds4.des.no> <86aa3qypb3.fsf@ds4.des.no> Message-ID: On Fri, 9 Mar 2012, Dag-Erling Sm?rgrav wrote: > Damien Miller writes: > > According to the manpages it does. Could you please try this? > > If I apply the patch and run autoreconf, config.h.in no longer contains > an entry for HAVE_OPENPTY, so although the configure script finds > openpty() in libutil, it still tries to build bsd-compat/openpty.c. okay, try this one please: Index: configure.ac =================================================================== RCS file: /var/cvs/openssh/configure.ac,v retrieving revision 1.487 diff -u -p -r1.487 configure.ac --- configure.ac 23 Feb 2012 23:40:43 -0000 1.487 +++ configure.ac 13 Mar 2012 03:41:46 -0000 @@ -1127,7 +1127,12 @@ dnl Checks for libutil functions AC_CHECK_HEADERS([libutil.h]) AC_SEARCH_LIBS([login], [util bsd], [AC_DEFINE([HAVE_LOGIN], [1], [Define if your libraries define login()])]) -AC_CHECK_FUNCS([fmt_scaled logout updwtmp logwtmp]) +AC_SEARCH_LIBS([logout], [util]) +AC_SEARCH_LIBS([updwtmp], [util]) +AC_SEARCH_LIBS([logwtmp], [util]) +AC_SEARCH_LIBS([fmt_scaled], [util]) +AC_SEARCH_LIBS([openpty], [util]) +AC_CHECK_FUNCS([fmt_scaled logout updwtmp logwtmp openpty]) AC_FUNC_STRFTIME @@ -1507,7 +1512,6 @@ AC_CHECK_FUNCS([ \ nsleep \ ogetaddrinfo \ openlog_r \ - openpty \ poll \ prctl \ pstat \ From des at des.no Wed Mar 14 01:46:42 2012 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Tue, 13 Mar 2012 15:46:42 +0100 Subject: Call for testing: OpenSSH-6.0 In-Reply-To: (Damien Miller's message of "Tue, 13 Mar 2012 14:42:17 +1100 (EST)") References: <868vjxbkkd.fsf@ds4.des.no> <86aa3qypb3.fsf@ds4.des.no> Message-ID: <86ipi8y2wd.fsf@ds4.des.no> Damien Miller writes: > Dag-Erling Sm?rgrav writes: > > If I apply the patch and run autoreconf, config.h.in no longer contains > > an entry for HAVE_OPENPTY, so although the configure script finds > > openpty() in libutil, it still tries to build bsd-compat/openpty.c. > okay, try this one please: That fixes openpty - but now it fails to build loginrec.c. FreeBSD has UTMPX, and config.h is correct in that respect, but it still tries to build parts of loginrec.c that are [UW]TMP-specific. See http://www.des.no/openssh/openssh-SNAP-20120313 for complete logs and config.h. DES -- Dag-Erling Sm?rgrav - des at des.no From openssh-unix-dev at oh3mqu.pp.hyper.fi Wed Mar 14 03:30:37 2012 From: openssh-unix-dev at oh3mqu.pp.hyper.fi (Ari Saastamoinen) Date: Tue, 13 Mar 2012 18:30:37 +0200 (EET) Subject: chroot directory ownership Message-ID: Angel Gonzalez wrote: > Just one example. > If the user is the owner of /, he could move away /etc and replace it > with its own one, providing a /etc/passwd under its control. > > You may think a user-owned chroot is not a problem for your setup, and > it may not be, or there may be a way you don't yet known (or opened by a > config change). Having a root-owned / is *much* safer. I think that most used configuration of this chrooting is for sftp-only users. With this kind of config it is not a problem if /user creates etc in his home directory. Match Group sftp-only AllowTCPForwarding no X11Forwarding no ForceCommand internal-sftp ChrootDirectory %h At least documentation should have note, that this reasonable looking configuration is not valid. Or if devs think that this shouldn't be allowed by default. Maybe they can add a configuration entry "TrustMeIKnowWhatIAmDoing yes" to make this configuration possible. (Currently I must use proftpd with sftp module, but I would like to use opensshd so there is only one software to handle both, file transfers and remote shells) -- Ari Saastamoinen From reza.hedayat at adnovum.ch Wed Mar 14 22:07:21 2012 From: reza.hedayat at adnovum.ch (Reza Hedayat) Date: Wed, 14 Mar 2012 12:07:21 +0100 Subject: Invalid user name: function okname() in scp.c In-Reply-To: <4F572BA6.6010003@adnovum.ch> References: <4F56500F.9040808@adnovum.ch> <4F565A2E.5040800@gmail.com> <4F572BA6.6010003@adnovum.ch> Message-ID: <4F607BE9.30508@adnovum.ch> Hi ?ngel I just wanted to enquire if there is a chance that you will remove the hash sign (#) validation from the OpenSSH code base. Even the attempt to escape the # character results in rejection of the complete command by SCP. SSH client and SFTP work perfectly with # characters in user names, it is just SCP that rejects it. On the server side there are IBM AS/400 systems having usernames containing # characters, which are completely valid, legal and commonplace on that platform. Best wishes Reza On 03/07/12 10:34, Reza Hedayat wrote: > Hi ?ngel > > Thanks a lot for your quick answer. > You're right, this use case is very rare, but unfortunately there > exist some cases. :( > > Cheers > Reza > > > > > On 03/06/12 19:40, ?ngel Gonz?lez wrote: >> On 06/03/12 18:57, Reza Hedayat wrote: >>> Hi OpenSSH developers >>> >>> In the source file *scp.c* there is a function called *okname(char >>> *cp0)* that validates the entered username by using the scp command as >>> follows: >>> >>> ( Fragment scp.c skipped) >>> >>> Thereby, usernames that contain the hash sign (#) are rejected. Is >>> there a good reason why this logic was introduced? >>> If there is no reason, so is it possible to remove the mentioned >>> case-statement? >>> >>> I thank you in advance for your help and remain with best wishes >>> Reza Hedayat >> It's trying to avoiod shell special characters (quotes, backticks, >> spaces...). The # introduces a comment in the shell (would need >> escaping), so that's surely the reason it's forbidden. >> You could replace it if you were sure the username is never used >> unquoted. >> Having a # in the user name is very rare, though. > -- AdNovum Informatik AG Reza Hedayat, Software Engineer Dipl. Informatik-Ing. FH Roentgenstrasse 22, CH-8005 Zurich mailto:reza.hedayat at adnovum.ch phone: +41 44 272 6111, fax: +41 44 272 6312 http://www.adnovum.ch AdNovum Locations: Bern, Budapest, Singapore, Zurich (HQ) From hmckinno at avaya.com Sat Mar 17 06:38:13 2012 From: hmckinno at avaya.com (Mckinnon, Heather (Heather)) Date: Fri, 16 Mar 2012 15:38:13 -0400 Subject: Host Key verification issue Message-ID: <2964187B-DFC0-4128-97AC-A0F688129486@avaya.com> Hello, I have script that I run remotely on a server, using ssh config with a 'command' call in the authorized keys file. I can successfully run this from one of my servers, but when I try from 2 other machines, I receive a Host Key Verification Failed error. When I remove the 'command' from the call from authorized keys on the remote server, I can successfully connect to the server. For security reasons, I do not want to do a direct connection to the server. I have removed the server name from the known_hosts file and still I cannot get this to work. Has anyone seen this issue before? In verbose mode, it gets through to the sending of the command, then fails: debug1: Sending command: debug2: channel 0: request exec confirm 1 debug2: fd 3 setting TCP_NODELAY debug2: callback done debug2: channel 0: open confirm rwindow 0 rmax 32768 debug3: Wrote 224 bytes for a total of 2037 debug2: channel 0: rcvd adjust 2097152 debug2: channel_input_status_confirm: type 99 id 0 debug2: exec request accepted on channel 0 debug2: channel 0: rcvd ext data 31 Host key verification failed. debug2: channel 0: written 31 to fed 6 Any idea why this would fail? Cheers, and thanks for any insight you may have. Heather From vinschen at redhat.com Sat Mar 17 08:51:50 2012 From: vinschen at redhat.com (Corinna Vinschen) Date: Fri, 16 Mar 2012 22:51:50 +0100 Subject: [PATCH/cygwin]: Explicitely undefine _WIN32 Message-ID: <20120316215150.GE19107@calimero.vinschen.de> Hi, I've just trieed to build OpenSSH on Cygwin with Kerberos support enabled, and while doing that I stumbled over a problem: The openbsd-compat/bsd-cygwin_util.h header include a Windows header, and depending on which Win32 header files are included (Mingw32/Mingw64) that can result in a `#define _WIN32'. This in turn can break linking against some packages. In my case it's GSSAPI from the heimdal package. The header file /usr/include/gssapi/gssapi.h contains code like this: #if defined(_WIN32) #define GSSAPI_LIB_FUNCTION __declspec(dllimport) #define GSSAPI_LIB_CALL __stdcall #define GSSAPI_LIB_VARIABLE __declspec(dllimport) #else #define GSSAPI_LIB_FUNCTION #define GSSAPI_LIB_CALL #define GSSAPI_LIB_VARIABLE #endif The declspecs are right for the native Win32 Heimdal build, but they are wrong for the Cygwin library, so linking against libgssapi fails. Therefore, the below patch explicitely undefined _WIN32 so as not to break other libraries. Can somebody with checkin rights please apply this patch? Index: openbsd-compat/bsd-cygwin_util.h =================================================================== RCS file: /cvs/openssh/openbsd-compat/bsd-cygwin_util.h,v retrieving revision 1.13 diff -u -p -r1.13 bsd-cygwin_util.h --- openbsd-compat/bsd-cygwin_util.h 17 Aug 2011 01:31:09 -0000 1.13 +++ openbsd-compat/bsd-cygwin_util.h 16 Mar 2012 21:51:21 -0000 @@ -37,6 +37,7 @@ #undef ERROR #include +#undef _WIN32 #include #include Thanks, Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From keisial at gmail.com Sat Mar 17 11:21:56 2012 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Sat, 17 Mar 2012 01:21:56 +0100 Subject: Invalid user name: function okname() in scp.c In-Reply-To: <4F607BE9.30508@adnovum.ch> References: <4F56500F.9040808@adnovum.ch> <4F565A2E.5040800@gmail.com> <4F572BA6.6010003@adnovum.ch> <4F607BE9.30508@adnovum.ch> Message-ID: <4F63D924.6020708@gmail.com> On 14/03/12 12:07, Reza Hedayat wrote: > Hi ?ngel > > I just wanted to enquire if there is a chance that you will remove the > hash sign (#) validation from the OpenSSH code base. > > Even the attempt to escape the # character results in rejection of the > complete command by SCP. > SSH client and SFTP work perfectly with # characters in user names, it > is just SCP that rejects it. > On the server side there are IBM AS/400 systems having usernames > containing # characters, which are completely valid, legal and > commonplace on that platform. > > Best wishes > Reza Hello Reza, I gave it a go. See the attached patch. I just allowed # in the middle of a word, which _should_ be safe to do, as in it's only special for a shell as the first token character (per POSIX rules). It seems to work fine. Best regards -------------- next part -------------- A non-text attachment was scrubbed... Name: okname-v1.patch Type: text/x-patch Size: 335 bytes Desc: not available URL: From peter at stuge.se Sat Mar 17 13:47:13 2012 From: peter at stuge.se (Peter Stuge) Date: Sat, 17 Mar 2012 03:47:13 +0100 Subject: [PATCH/cygwin]: Explicitely undefine _WIN32 In-Reply-To: <20120316215150.GE19107@calimero.vinschen.de> References: <20120316215150.GE19107@calimero.vinschen.de> Message-ID: <20120317024713.19694.qmail@stuge.se> Corinna Vinschen wrote: > +++ openbsd-compat/bsd-cygwin_util.h 16 Mar 2012 21:51:21 -0000 > @@ -37,6 +37,7 @@ > #undef ERROR > > #include > +#undef _WIN32 > #include > #include Maybe it needs to be guarded: #ifdef _WIN32 #undef #endif //Peter From vinschen at redhat.com Sat Mar 17 21:10:21 2012 From: vinschen at redhat.com (Corinna Vinschen) Date: Sat, 17 Mar 2012 11:10:21 +0100 Subject: [PATCH/cygwin]: Explicitely undefine _WIN32 In-Reply-To: <20120317024713.19694.qmail@stuge.se> References: <20120316215150.GE19107@calimero.vinschen.de> <20120317024713.19694.qmail@stuge.se> Message-ID: <20120317101021.GF19107@calimero.vinschen.de> On Mar 17 03:47, Peter Stuge wrote: > Corinna Vinschen wrote: > > +++ openbsd-compat/bsd-cygwin_util.h 16 Mar 2012 21:51:21 -0000 > > @@ -37,6 +37,7 @@ > > #undef ERROR > > > > #include > > +#undef _WIN32 > > #include > > #include > > Maybe it needs to be guarded: Oh, right. New patch attached. I also added a comment so everyone knows what that's good for. Index: openbsd-compat/bsd-cygwin_util.h =================================================================== RCS file: /cvs/openssh/openbsd-compat/bsd-cygwin_util.h,v retrieving revision 1.13 diff -u -p -r1.13 bsd-cygwin_util.h --- openbsd-compat/bsd-cygwin_util.h 17 Aug 2011 01:31:09 -0000 1.13 +++ openbsd-compat/bsd-cygwin_util.h 17 Mar 2012 10:10:04 -0000 @@ -40,6 +40,12 @@ #include #include +/* Make sure _WIN32 isn't defined later in the code, otherwise headers from + other packages might get the wrong idea about the target system. */ +#ifdef _WIN32 +#undef _WIN32 +#endif + int binary_open(const char *, int , ...); int check_ntsec(const char *); char **fetch_windows_environment(void); Thanks, Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From chris at qwirx.com Sat Mar 17 23:07:37 2012 From: chris at qwirx.com (Chris Wilson) Date: Sat, 17 Mar 2012 12:07:37 +0000 (GMT) Subject: Host Key verification issue In-Reply-To: <2964187B-DFC0-4128-97AC-A0F688129486@avaya.com> References: <2964187B-DFC0-4128-97AC-A0F688129486@avaya.com> Message-ID: Hi Heather, On Fri, 16 Mar 2012, Mckinnon, Heather (Heather) wrote: > I have script that I run remotely on a server, using ssh config with a > 'command' call in the authorized keys file. I can successfully run this > from one of my servers, but when I try from 2 other machines, I receive > a Host Key Verification Failed error. Does the script behave differently depending on which server it's called from? > In verbose mode, it gets through to the sending of the command, then fails: > > debug1: Sending command: > debug2: channel 0: request exec confirm 1 > debug2: fd 3 setting TCP_NODELAY > debug2: callback done > debug2: channel 0: open confirm rwindow 0 rmax 32768 > debug3: Wrote 224 bytes for a total of 2037 > debug2: channel 0: rcvd adjust 2097152 > debug2: channel_input_status_confirm: type 99 id 0 > debug2: exec request accepted on channel 0 > debug2: channel 0: rcvd ext data 31 > Host key verification failed. > debug2: channel 0: written 31 to fed 6 I think the secure channel to the server is already open at this point, so the "Host key verification failed" message is being output by the command that you're running on the remote server. Perhaps it's SSHing to another server whose host key it hasn't saved yet, or which has changed? Cheers, Chris. -- _____ __ _ \ __/ / ,__(_)_ | Chris Wilson Cambs UK | / (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Ruby/Perl/SQL Developer | \__/_/_/_//_/___/ | We are GNU : free your mind & your software | From glenn at zewt.org Sun Mar 18 01:07:06 2012 From: glenn at zewt.org (Glenn Maynard) Date: Sat, 17 Mar 2012 09:07:06 -0500 Subject: [PATCH/cygwin]: Explicitely undefine _WIN32 In-Reply-To: <20120317101021.GF19107@calimero.vinschen.de> References: <20120316215150.GE19107@calimero.vinschen.de> <20120317024713.19694.qmail@stuge.se> <20120317101021.GF19107@calimero.vinschen.de> Message-ID: On Sat, Mar 17, 2012 at 5:10 AM, Corinna Vinschen wrote: > +/* Make sure _WIN32 isn't defined later in the code, otherwise headers > from > + other packages might get the wrong idea about the target system. */ > +#ifdef _WIN32 > +#undef _WIN32 > +#endif > #undef for an undefined macro should be a no-op, so the #ifdef should be unnecessary. -- Glenn Maynard From vinschen at redhat.com Mon Mar 19 20:28:43 2012 From: vinschen at redhat.com (Corinna Vinschen) Date: Mon, 19 Mar 2012 10:28:43 +0100 Subject: [PATCH/cygwin]: Explicitely undefine _WIN32 In-Reply-To: References: <20120316215150.GE19107@calimero.vinschen.de> <20120317024713.19694.qmail@stuge.se> <20120317101021.GF19107@calimero.vinschen.de> Message-ID: <20120319092843.GN19107@calimero.vinschen.de> On Mar 17 09:07, Glenn Maynard wrote: > On Sat, Mar 17, 2012 at 5:10 AM, Corinna Vinschen wrote: > > > +/* Make sure _WIN32 isn't defined later in the code, otherwise headers > > from > > + other packages might get the wrong idea about the target system. */ > > +#ifdef _WIN32 > > +#undef _WIN32 > > +#endif > > > > #undef for an undefined macro should be a no-op, so the #ifdef should be > unnecessary. You're right. BUt it looks cleaner, doesn't it? Anyway, whoever has checkin rights, please apply any one of the patches you like better. Thanks, Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From hmckinno at avaya.com Tue Mar 20 01:15:02 2012 From: hmckinno at avaya.com (Mckinnon, Heather (Heather)) Date: Mon, 19 Mar 2012 10:15:02 -0400 Subject: Host Key verification issue In-Reply-To: References: <2964187B-DFC0-4128-97AC-A0F688129486@avaya.com> Message-ID: Chris - thank you very very much for your help. The issue was that one of the first lines in the remote script was an 'scp' from the local server to the remote server, and the authorized keys on the source server did not include my key from my remote sever. I am able to fully run my script. Cheers, and thanks again. Heather On 2012-03-17, at 8:07 AM, Chris Wilson wrote: > Hi Heather, > > On Fri, 16 Mar 2012, Mckinnon, Heather (Heather) wrote: > >> I have script that I run remotely on a server, using ssh config with a >> 'command' call in the authorized keys file. I can successfully run this >> from one of my servers, but when I try from 2 other machines, I receive >> a Host Key Verification Failed error. > > Does the script behave differently depending on which server it's called > from? > >> In verbose mode, it gets through to the sending of the command, then fails: >> >> debug1: Sending command: >> debug2: channel 0: request exec confirm 1 >> debug2: fd 3 setting TCP_NODELAY >> debug2: callback done >> debug2: channel 0: open confirm rwindow 0 rmax 32768 >> debug3: Wrote 224 bytes for a total of 2037 >> debug2: channel 0: rcvd adjust 2097152 >> debug2: channel_input_status_confirm: type 99 id 0 >> debug2: exec request accepted on channel 0 >> debug2: channel 0: rcvd ext data 31 >> Host key verification failed. >> debug2: channel 0: written 31 to fed 6 > > I think the secure channel to the server is already open at this point, so > the "Host key verification failed" message is being output by the command > that you're running on the remote server. > > Perhaps it's SSHing to another server whose host key it hasn't saved yet, > or which has changed? > > Cheers, Chris. > -- > _____ __ _ > \ __/ / ,__(_)_ | Chris Wilson Cambs UK | > / (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Ruby/Perl/SQL Developer | > \__/_/_/_//_/___/ | We are GNU : free your mind & your software | From alex at alemate.ru Tue Mar 20 20:10:42 2012 From: alex at alemate.ru (alex at alemate.ru) Date: Tue, 20 Mar 2012 13:10:42 +0400 (MSK) Subject: [patch] Threading support in ssh-agent In-Reply-To: References: Message-ID: Hi all, Is there any hope for threaded ssh-agent to be included in the main trunk? On Sun, 11 Mar 2012, Alexander V Alekseev wrote: > Hi all! > > I do not know openssh patch policy so I am just sending > the patch to the mailing list. Sorry for inconvenience. > Ssh-agent seems to be too slow if you need to access thousands of > servers. This is a simple patch to enable threading in ssh2 authentication. > Patch adds "-p numthreads" option and defaults to the number of processors. > > I've tested it as I could, but unfortunately I could check it > only in Linux environment. Though it shouldn't break anything. > > Bye. Alex. From djm at mindrot.org Wed Mar 21 10:19:56 2012 From: djm at mindrot.org (Damien Miller) Date: Wed, 21 Mar 2012 10:19:56 +1100 (EST) Subject: [patch] Threading support in ssh-agent In-Reply-To: References: Message-ID: On Tue, 20 Mar 2012, alex at alemate.ru wrote: > Hi all, > > Is there any hope for threaded ssh-agent to be included in the > main trunk? No, sorry - we have no desire to make any part of OpenSSH multithreaded, especially something as sensitive as ssh-agent. We might consider an alternate design that used fork() if it were simple enough, but I'd encourage you to hold off as I plan on refactoring some of the agent code in the next release. -d From thomas at habets.se Fri Mar 23 00:07:31 2012 From: thomas at habets.se (Thomas Habets) Date: Thu, 22 Mar 2012 13:07:31 +0000 Subject: TPM-protected client keys Message-ID: Since OpenSSH has PKCS11 support nowadays that means it should work with a TPM chip, right? Has anyone done it and would like to share instructions for setting it up? Something like this but for SSH: http://blog.habets.pp.se/2012/02/TPM-backed-SSL -- typedef struct me_s { ?char name[] ? ? ?= { "Thomas Habets" }; ?char email[] ? ? = { "thomas at habets.pp.se" }; ?char kernel[] ? ?= { "Linux" }; ?char *pgpKey[] ? = { "http://www.habets.pp.se/pubkey.txt" }; ?char pgp[] = { "A8A3 D1DD 4AE0 8467 7FDE ?0945 286A E90A AD48 E854" }; ?char coolcmd[] ? = { "echo '. ./_&. ./_'>_;. ./_" }; } me_t; From calestyo at scientia.net Mon Mar 26 03:36:54 2012 From: calestyo at scientia.net (Christoph Anton Mitterer) Date: Sun, 25 Mar 2012 18:36:54 +0200 Subject: how to speed up OpenSSH command execution (and a speed analysis) Message-ID: <7fc6cf717a19d227d08de9970cf6a77d@scientia.net> Hi. I recently did some investigation about how to get out the last microseconds of executing commands via OpenSSH on remote host (of course I'm using ConnectMaster). MOTIVATION: I'm introducing Nagios (well actualla Icinga) at the local institute. We have many active checks that must run locally on the remote hosts. The "best" way to do this is using NRPE (Nagios Remote Plugin Executor), which runs a daemon listening on a port, waiting for commands to be executed. The problem with NRPE is that it's inherently insecure (even when using the fake-SSL mode) it provides (as extensively disscussed here [0], [1] and [2]). Also executing commands on a remote host is bussiness the "belongs" to SSH and NRPE more or less duplicates this. Another reason why NRPE is broken is, that the mode in which argument passing (to the check scripts) is enabled is already marked as being unsecure. Why have NRPE then? - It allows only certain commands to be executed => With SSH this could however be done, too, I guess, by means as rssh. - It's much faster. => What I try to "solve" here? Why not using stunnel + NRPE? => This would still allow any local user on the remote host to contact the running NRPE daemon, and execute commands. This might be a security risk, e.g. if the NRPE has sudo rights or so. What's the goal? - Drop NRPE and use SSH instead of it, if the latter can be made as fast (or nearly as fast) as NRPE. - Use rssh to restrict the commands that may be run. - Use SSH-keys to allow the Nagios node to login to the (rssh-restricted) remote host. USING CONTROLMASTER: I guess it's inevitable to use ControlMaster for the connections from the Nagios host to the remot hosts. The actual connections for the commands usually close immediately, so a spawner is required that keeps up a connection for ALL checked hosts. I.e. something like: for each host ssh -f -N host Problems here: - What other options to use (largely for the sake of speed and security)? * -o ServerAliveInterval=30 ? * -C ? * -a -k -x ? * others? - How to spawn that first connection? I'd prefer that ssh has another mode, e.g. ControlMaster autoswpan, which makes about the following: When the first time a "normal" command is executed, e.g. ssh example.host.org check_load it actually does a ssh -f -N host and uses that one to do the ssh example.host.org check_load That way I wouldn't have to take care on * spawning the master sessions * restarting them, when they die for some reason * they would be only started when really required the frist time Ideally, there would be a way to timeout those automatically spawned master sessions. E.g. when not used for a day, stop it. ANALYSIS: I made some tests on the speed of command executiong with NRPE, SSH, SSH+NRPE, etc.: The check_load command was defined as /usr/lib/nagios/plugins/check_load -w 15,10,5 -c 30,25,20 in NRPE. The sshd_config of the remote host is found below[3]. The nagtest user on the remote host has: - this /etc/passwd entry: nagtest:x:54115:100::/home/nagtest:/bin/bash - a .bashrc and .profile in his homedir 1) NRPE (with it's fake-SSL mode) alone, no SSH or so at all: # time /usr/lib/nagios/plugins/check_nrpe -H host.example.org -c check_load OK - load average: 0.00, 0.02, 0.00|load1=0.000;15.000;30.000;0; load5=0.020;10.000;25.000;0; load15=0.000;5.000;20.000;0; real 0m0.047s user 0m0.000s sys 0m0.004s # time /usr/lib/nagios/plugins/check_nrpe -H host.example.org -c check_load OK - load average: 0.00, 0.02, 0.00|load1=0.000;15.000;30.000;0; load5=0.020;10.000;25.000;0; load15=0.000;5.000;20.000;0; real 0m0.008s user 0m0.004s sys 0m0.000s => The first time it#s quite slow, I guess because of the DNS lookup, but sub- sequent invocations are really fast (0.008s) 2) NRPE (withOUT it's fake-SSL mode) alone, no SSH or so at all: # time /usr/lib/nagios/plugins/check_nrpe -H host.example.org -c check_load -n OK - load average: 0.00, 0.00, 0.00|load1=0.000;15.000;30.000;0; load5=0.000;10.000;25.000;0; load15=0.000;5.000;20.000;0; real 0m0.006s user 0m0.004s sys 0m0.000s => It's even faster than (1). So given that NRPEs SSL is absolutely useless in anyway, one should always just disable it. 3) NRPE (withOUT it's fake-SSL mode) and with tunneling the connection over SSH via port-forwarding, NO(!) ControlMaster set: # ssh nagtest at host.example.org -L 2000:host.example.org:5666 -N (running everything under the nagtest user, the NRPE daemon listens on port 5666) (running check_nrpe on localhost:2000 in order to use the port-forwarding) # time /usr/lib/nagios/plugins/check_nrpe -p 2000 -H localhost -c check_load -n OK - load average: 0.31, 0.07, 0.02|load1=0.310;15.000;30.000;0; load5=0.070;10.000;25.000;0; load15=0.020;5.000;20.000;0; real 0m0.023s user 0m0.004s sys 0m0.000s real 0m0.010s user 0m0.004s sys 0m0.000s real 0m0.017s user 0m0.004s sys 0m0.000s real 0m0.006s user 0m0.004s sys 0m0.000s => On the first few invocations, time varied quite a lot (perhaps the remove system was under load). But then it got as fast as NRPE without SSH tunneling! This is really interesting, as it shows, I guess, that it's not the encryption layer of SSH that makes things slow Sidenode: Why don't I just stop here, and use NRPE tunneled over SSH? Cause NRPE would still be insecure and could be invoked on the localhost by other users 4) From now on, no more NRPE. Plain SSH, no special options, no ControlMaster, obviously no port-forwarding: # time ssh nagtest at host.example.org /usr/lib/nagios/plugins/check_load -w 15,10,5 -c 30,25,20 OK - load average: 0.01, 0.05, 0.05|load1=0.010;15.000;30.000;0; load5=0.050;10.000;25.000;0; load15=0.050;5.000;20.000;0; real 0m0.126s user 0m0.036s sys 0m0.000s real 0m0.169s user 0m0.036s sys 0m0.000s => Once it was "fast" (0.126s), but all other times I've tested it was around 0.169s. Control Master setup: Host * ControlPath ~/.ssh/master-%l-%r@%h:%p ControlMaster auto 5) SSH with ControlMaster: Opening the background control master: # ssh -f -N nagtest@@host.example.org # time ssh nagtest at lcg-lrz-dc20.grid.lrz-muenchen.de /usr/lib/nagios/plugins/check_load -w 15,10,5 -c 30,25,20 OK - load average: 0.00, 0.00, 0.00|load1=0.000;15.000;30.000;0; load5=0.000;10.000;25.000;0; load15=0.000;5.000;20.000;0; real 0m0.045s user 0m0.004s sys 0m0.000s => Fastest result with SSH so far. 6) SSH with ControlMaster but dash as shell I thought maybe it's bash that is slow, so I changed the users shell to "dash". So I changed this in /etc/passwd. First I found out that this only takes effect when the Controls Master is restarted,... why? But apart from that, it had no impact on speed. 7) SSH with ControlMaster but ash as shell I made a test with ash as shell, where I actually got down to the 0.006s. But I couldn't reproduce this later. 8) SSH with ControlMaster but /bin/true as shell # time ssh nagtest at lcg-lrz-dc20.grid.lrz-muenchen.de /usr/lib/nagios/plugins/check_load -w 15,10,5 -c 30,25,20 real 0m0.040s user 0m0.004s sys 0m0.000s => As only true is executed, and no shell config files are read... it seems that the problem is not related to shell start up. MISCELLANEOUS Are there any further ways to speed things up? * I think disabling UseDNS isn't of that much use as it only affects the first control master connection, right? * Any ways, e.g. to speed up choice of the identity file? Or disabling everything but ssh-keys? etc. pp. So the question in the end is, can I somehow speed things even more up? If you need any further analysis work, just tell me. Thanks, Chris. [0] http://tracker.nagios.org/view.php?id=90 [1] http://tracker.nagios.org/view.php?id=125 [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=547092 [3] AllowUsers root nagtest ChallengeResponseAuthentication no PasswordAuthentication no RSAAuthentication no Protocol 2 Ciphers aes256-cbc,aes192-cbc,aes128-cbc,aes256-ctr,aes192-ctr,aes128-ctr,blowfish-cbc MACs hmac-sha1,hmac-ripemd160 ClientAliveInterval 30 TCPKeepAlive no AcceptEnv LANG LC_* X11Forwarding yes Subsystem sftp /usr/lib/openssh/sftp-server => I really wouldn't want to change the Ciphers to something weaker! From apb at cequrux.com Mon Mar 26 04:32:39 2012 From: apb at cequrux.com (Alan Barrett) Date: Sun, 25 Mar 2012 19:32:39 +0200 Subject: how to speed up OpenSSH command execution (and a speed analysis) In-Reply-To: <7fc6cf717a19d227d08de9970cf6a77d@scientia.net> References: <7fc6cf717a19d227d08de9970cf6a77d@scientia.net> Message-ID: <20120325173239.GA767@apb-laptoy.apb.alt.za> On Sun, 25 Mar 2012, Christoph Anton Mitterer wrote: >- How to spawn that first connection? > I'd prefer that ssh has another mode, e.g. ControlMaster autoswpan, > which makes about the following: > When the first time a "normal" command is executed, e.g. > ssh example.host.org check_load > it actually does a > ssh -f -N host > and uses that one to do the > ssh example.host.org check_load "ControlMaster auto" is supposed to do that. > Ideally, there would be a way to timeout those automatically spawned > master sessions. E.g. when not used for a day, stop it. "ControlPersist 24h" is supposed to do that. --apb (Alan Barrett) From calestyo at scientia.net Mon Mar 26 06:51:30 2012 From: calestyo at scientia.net (Christoph Anton Mitterer) Date: Sun, 25 Mar 2012 21:51:30 +0200 Subject: how to speed up OpenSSH command execution (and a speed analysis) In-Reply-To: <20120325173239.GA767@apb-laptoy.apb.alt.za> References: <7fc6cf717a19d227d08de9970cf6a77d@scientia.net> <20120325173239.GA767@apb-laptoy.apb.alt.za> Message-ID: <1332705090.3434.52.camel@fermat.scientia.net> Hi Alan, et all. On Sun, 2012-03-25 at 19:32 +0200, Alan Barrett wrote: > "ControlMaster auto" is supposed to do that. This alone wouldn't help (in my scenario[0], right? I'm already using it and when the connection that initialises the master is closed the then it goes full away. But... > "ControlPersist 24h" is supposed to do that. ... this is as far as I can see what solves both,... Thanks for the hint, I haven't seen it before, as my ssh on which I tested it was too old. I'll try later and see whether it does exactly what I want. But the main problem is the speed thingy,... and I have found something really strange (but also interesting): I played around with -t. Still having no ControlPersist set. I always do: 1) killing any old control masters and starting a new one with: # ssh -f -N nagtest at host.example.org 2) measuring the time of the remote execution of the check script # time ssh nagtest at host.example.org a) Tried around with -a -x -k -C: They seem to change nothing with respect to speed b) Then I played around with -t, both with and without the options from (a) above: Here comes the weird part: - It does basically NOT matter, whether I set -t on creating the control master (step (1) above). In step (2) (the actual command executions): - When the FIRST time, I execute a command, -t is used,... then speed get much better, and I get times around 0.006 (s) which is the same that NRPE (even without the fake-SSL) required. GREAT - For subsequent tries (with the same Control Master)... it doesn't matter whether -t is used or not,.. it stays between 0.014-0.010s. BUT - When the FIRST time, I execute a command, -t is NOT used,... then speed stays at the boring 0.045s. - For subsequent tries (with the same Control Master)... it doesn't matter whether -t is used or not,.. it stays at around 0.045s. CONCLUSIONS: I) Something seems to be fishy there, given that it * depends on the FIRST command executed using -t * while most other options get "fix" by starting the ControlMaster the -t option seem to be not "set" by it. II) With -t (and ControlMaster) you can speed up SSH dramatically (effectively making NRPE absolutely useless). PROBLEMS LEFT: Apart from the strange point (I) above... (shall I open a bug on this?) there is one "big" problem left: Whenever I use "-t" in the command execution step (that was (2) above) I first get the output from the script, e.g.: # time /usr/lib/nagios/plugins/check_nrpe -H host.example.org -c check_load OK - load average: 0.00, 0.02, 0.00|load1=0.000;15.000;30.000;0; load5=0.020;10.000;25.000;0; load15=0.000;5.000;20.000;0; but directly afterwards, ssh prints the following on stderr: Shared connection to host.example.org closed. real 0m0.006s user 0m0.004s sys 0m0.000s This is (in my case quite annoying, as it seems to be useless (or does anyone know what it means?) and it disturbs Nagios. Of course I could just redirect stderr to /dev/null or write another wrapper that filters this. But the former would hide real errors, too, and the later would just cost time again. Another thing: Perhaps disabling the pseudo-tty allocation is something which I shouldn't want with my Nagios checks and I just don't see some problems?! (I'm really no expert with respect to the pseudo tty stuff.) So if some experts have more knowledge on -t and the pseudo-ttys... just tell me. Cheers, Chris. [0] Nagios schedules the checks typically not at the same time,.. so multiple SSH connections wouldn't get opened concurrently, but subsequentially. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5677 bytes Desc: not available URL: From keisial at gmail.com Mon Mar 26 08:27:11 2012 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Sun, 25 Mar 2012 23:27:11 +0200 Subject: how to speed up OpenSSH command execution (and a speed analysis) In-Reply-To: <1332705090.3434.52.camel@fermat.scientia.net> References: <7fc6cf717a19d227d08de9970cf6a77d@scientia.net> <20120325173239.GA767@apb-laptoy.apb.alt.za> <1332705090.3434.52.camel@fermat.scientia.net> Message-ID: <4F6F8DAF.9030805@gmail.com> On 25/03/12 21:51, Christoph Anton Mitterer wrote: > BUT > > - When the FIRST time, I execute a command, -t is NOT used,... then > speed stays at the boring 0.045s. > - For subsequent tries (with the same Control Master)... it doesn't > matter whether -t is used or not,.. it stays at around 0.045s. > > > CONCLUSIONS: > I) Something seems to be fishy there, given that it > * depends on the FIRST command executed using -t > * while most other options get "fix" by starting the ControlMaster > the -t option seem to be not "set" by it. > II) With -t (and ControlMaster) you can speed up SSH dramatically > (effectively making NRPE absolutely useless). Maybe your nrpe command behaves differently if it is run with a pseudo-terminal ? I don't know why it would be slower the second time, but perhaps it could be detecting that it an "already used terminal" and trying to clean that (opening yet another terminal? creating a new process group?), which end up being expensive. What are the results when you employ a different command? I open the master with: SSH_ASKPASS=true ssh -f -o ControlMaster=yes -oControlPath=/tmp/localhost -M localhost -N Then run time ssh -oControlPath=/tmp/localhost localhost true or time ssh -t -oControlPath=/tmp/localhost localhost true I get about 0m0.008s for the non-tty case and 0m0.009s with -t (with some deviations, there are -t of 0.008s and yet in some cases it is up to 0.011s) which is consistent with the fact that it needs to do more work when allocating a tty. > PROBLEMS LEFT: > Apart from the strange point (I) above... (shall I open a bug on this?) > there is one "big" problem left: > Whenever I use "-t" in the command execution step (that was (2) above) I > first get the output from the script, e.g.: > > # time /usr/lib/nagios/plugins/check_nrpe -H host.example.org -c check_load > OK - load average: 0.00, 0.02, 0.00|load1=0.000;15.000;30.000;0; load5=0.020;10.000;25.000;0; load15=0.000;5.000;20.000;0; > > but directly afterwards, ssh prints the following on stderr: > Shared connection to host.example.org closed. Call the client ssh with -q parameter to remove this diagnostic. Best regards From calestyo at scientia.net Mon Mar 26 08:38:41 2012 From: calestyo at scientia.net (Christoph Anton Mitterer) Date: Sun, 25 Mar 2012 23:38:41 +0200 Subject: how to speed up OpenSSH command execution (and a speed analysis) In-Reply-To: <4F6F8DAF.9030805@gmail.com> References: <7fc6cf717a19d227d08de9970cf6a77d@scientia.net> <20120325173239.GA767@apb-laptoy.apb.alt.za> <1332705090.3434.52.camel@fermat.scientia.net> <4F6F8DAF.9030805@gmail.com> Message-ID: <1332711521.3434.59.camel@fermat.scientia.net> On Sun, 2012-03-25 at 23:27 +0200, ?ngel Gonz?lez wrote: > Maybe your nrpe command behaves differently if it is run with a > pseudo-terminal ? For me, it happens not just with the nagios commands, but also when I e.g. execute "true" remotely. > What are the results when you employ a different command? I just tried this: ~/.ssh/config has about: ControlMaster auto ControlPath something ControlPersist yes When I run # time ssh nagtest at host.example.org true First time: 0.169s Subsequent times: ~0.044s When I run # time ssh -t nagtest at host.example.org true First time: 0.132s Subsequent times: ~0.007s Actually, already the first invocation is faster (for me) when -t is used. > I get about 0m0.008s for the non-tty case and 0m0.009s with -t > (with some deviations, there are -t of 0.008s and yet in some cases it > is up to 0.011s) > which is consistent with the fact that it needs to do more work when > allocating a tty. Strange,.. I cannot reproduce this, for me it seems to be always relevant whether I use -t or not. > > but directly afterwards, ssh prints the following on stderr: > > Shared connection to host.example.org closed. > Call the client ssh with -q parameter to remove this diagnostic. I've thought about that, too, and actually it works,.. but don't I throw away "useful" warnings with this? Cheers, Chris. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5677 bytes Desc: not available URL: From val.baranov at duke.edu Mon Mar 26 11:04:51 2012 From: val.baranov at duke.edu (Val Baranov) Date: Mon, 26 Mar 2012 00:04:51 +0000 Subject: OpenSSH 5.9p1 compilation via gcc and cc - both produce "present but cannot be compiled" warnings -- AIX 6.1 TL7 SP3 Message-ID: configure: WARNING: fcntl.h: present but cannot be compiled configure: WARNING: fcntl.h: check for missing prerequisite headers? configure: WARNING: fcntl.h: see the Autoconf documentation configure: WARNING: fcntl.h: section "Present But Cannot Be Compiled" configure: WARNING: fcntl.h: proceeding with the compiler's result configure: WARNING: ## ------------------------------------------- ## configure: WARNING: ## Report this to openssh-unix-dev at mindrot.org ## configure: WARNING: ## ------------------------------------------- ## configure: WARNING: sys/audit.h: present but cannot be compiled configure: WARNING: sys/audit.h: check for missing prerequisite headers? configure: WARNING: sys/audit.h: see the Autoconf documentation configure: WARNING: sys/audit.h: section "Present But Cannot Be Compiled" configure: WARNING: sys/audit.h: proceeding with the compiler's result configure: WARNING: ## ------------------------------------------- ## configure: WARNING: ## Report this to openssh-unix-dev at mindrot.org ## configure: WARNING: ## ------------------------------------------- ## configure: WARNING: sys/stream.h: present but cannot be compiled configure: WARNING: sys/stream.h: check for missing prerequisite headers? configure: WARNING: sys/stream.h: see the Autoconf documentation configure: WARNING: sys/stream.h: section "Present But Cannot Be Compiled" configure: WARNING: sys/stream.h: proceeding with the compiler's result configure: WARNING: ## ------------------------------------------- ## configure: WARNING: ## Report this to openssh-unix-dev at mindrot.org ## configure: WARNING: ## ------------------------------------------- ## checking zlib.h usability... no checking zlib.h presence... yes configure: WARNING: zlib.h: present but cannot be compiled configure: WARNING: zlib.h: check for missing prerequisite headers? configure: WARNING: zlib.h: see the Autoconf documentation configure: WARNING: zlib.h: section "Present But Cannot Be Compiled" configure: WARNING: zlib.h: proceeding with the compiler's result configure: WARNING: ## ------------------------------------------- ## configure: WARNING: ## Report this to openssh-unix-dev at mindrot.org ## configure: WARNING: ## ------------------------------------------- ## From imorgan at nas.nasa.gov Tue Mar 27 03:24:34 2012 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Mon, 26 Mar 2012 09:24:34 -0700 Subject: OpenSSH 5.9p1 compilation via gcc and cc - both produce "present but cannot be compiled" warnings -- AIX 6.1 TL7 SP3 In-Reply-To: References: Message-ID: <20120326162434.GB4747@linux124.nas.nasa.gov> On Sun, Mar 25, 2012 at 19:04:51 -0500, Val Baranov wrote: > > > configure: WARNING: fcntl.h: present but cannot be compiled > configure: WARNING: fcntl.h: check for missing prerequisite headers? > configure: WARNING: fcntl.h: see the Autoconf documentation > configure: WARNING: fcntl.h: section "Present But Cannot Be Compiled" > configure: WARNING: fcntl.h: proceeding with the compiler's result > configure: WARNING: ## ------------------------------------------- ## > configure: WARNING: ## Report this to openssh-unix-dev at mindrot.org ## > configure: WARNING: ## ------------------------------------------- ## > > configure: WARNING: sys/audit.h: present but cannot be compiled > configure: WARNING: sys/audit.h: check for missing prerequisite headers? > configure: WARNING: sys/audit.h: see the Autoconf documentation > configure: WARNING: sys/audit.h: section "Present But Cannot Be Compiled" > configure: WARNING: sys/audit.h: proceeding with the compiler's result > configure: WARNING: ## ------------------------------------------- ## > configure: WARNING: ## Report this to openssh-unix-dev at mindrot.org ## > configure: WARNING: ## ------------------------------------------- ## > > configure: WARNING: sys/stream.h: present but cannot be compiled > configure: WARNING: sys/stream.h: check for missing prerequisite headers? > configure: WARNING: sys/stream.h: see the Autoconf documentation > configure: WARNING: sys/stream.h: section "Present But Cannot Be Compiled" > configure: WARNING: sys/stream.h: proceeding with the compiler's result > configure: WARNING: ## ------------------------------------------- ## > configure: WARNING: ## Report this to openssh-unix-dev at mindrot.org ## > configure: WARNING: ## ------------------------------------------- ## > > checking zlib.h usability... no > checking zlib.h presence... yes configure: WARNING: zlib.h: present but cannot be compiled > configure: WARNING: zlib.h: check for missing prerequisite headers? > configure: WARNING: zlib.h: see the Autoconf documentation > configure: WARNING: zlib.h: section "Present But Cannot Be Compiled" > configure: WARNING: zlib.h: proceeding with the compiler's result > configure: WARNING: ## ------------------------------------------- ## > configure: WARNING: ## Report this to openssh-unix-dev at mindrot.org ## > configure: WARNING: ## ------------------------------------------- ## > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev Have you checked config.log for any details? What OS is this on? What is your environment like; specicically CC, CFLAGS, etc? -- Iain Morgan From val.baranov at duke.edu Tue Mar 27 03:47:13 2012 From: val.baranov at duke.edu (Val Baranov) Date: Mon, 26 Mar 2012 16:47:13 +0000 Subject: OpenSSH 5.9p1 compilation via gcc and cc - both produce "present but cannot be compiled" warnings -- AIX 6.1 TL7 SP3 In-Reply-To: <20120326162434.GB4747@linux124.nas.nasa.gov> References: <20120326162434.GB4747@linux124.nas.nasa.gov> Message-ID: HI, I spoke about this with Kevin Brott kevin.brott at gmail.com and don't have any more questions - cc does work now and gcc seems to be too old for AIX 6.1 -will try the newest version. Thanks, Val -----Original Message----- From: Iain Morgan [mailto:imorgan at nas.nasa.gov] Sent: Monday, March 26, 2012 12:25 PM To: Val Baranov Cc: openssh-unix-dev at mindrot.org Subject: Re: OpenSSH 5.9p1 compilation via gcc and cc - both produce "present but cannot be compiled" warnings -- AIX 6.1 TL7 SP3 On Sun, Mar 25, 2012 at 19:04:51 -0500, Val Baranov wrote: > > > configure: WARNING: fcntl.h: present but cannot be compiled > configure: WARNING: fcntl.h: check for missing prerequisite headers? > configure: WARNING: fcntl.h: see the Autoconf documentation > configure: WARNING: fcntl.h: section "Present But Cannot Be Compiled" > configure: WARNING: fcntl.h: proceeding with the compiler's result > configure: WARNING: ## ------------------------------------------- ## > configure: WARNING: ## Report this to openssh-unix-dev at mindrot.org ## > configure: WARNING: ## ------------------------------------------- ## > > configure: WARNING: sys/audit.h: present but cannot be compiled > configure: WARNING: sys/audit.h: check for missing prerequisite headers? > configure: WARNING: sys/audit.h: see the Autoconf documentation > configure: WARNING: sys/audit.h: section "Present But Cannot Be Compiled" > configure: WARNING: sys/audit.h: proceeding with the compiler's result > configure: WARNING: ## ------------------------------------------- ## > configure: WARNING: ## Report this to openssh-unix-dev at mindrot.org ## > configure: WARNING: ## ------------------------------------------- ## > > configure: WARNING: sys/stream.h: present but cannot be compiled > configure: WARNING: sys/stream.h: check for missing prerequisite headers? > configure: WARNING: sys/stream.h: see the Autoconf documentation > configure: WARNING: sys/stream.h: section "Present But Cannot Be Compiled" > configure: WARNING: sys/stream.h: proceeding with the compiler's result > configure: WARNING: ## ------------------------------------------- ## > configure: WARNING: ## Report this to openssh-unix-dev at mindrot.org ## > configure: WARNING: ## ------------------------------------------- ## > > checking zlib.h usability... no > checking zlib.h presence... yes configure: WARNING: zlib.h: present but cannot be compiled > configure: WARNING: zlib.h: check for missing prerequisite headers? > configure: WARNING: zlib.h: see the Autoconf documentation > configure: WARNING: zlib.h: section "Present But Cannot Be Compiled" > configure: WARNING: zlib.h: proceeding with the compiler's result > configure: WARNING: ## ------------------------------------------- ## > configure: WARNING: ## Report this to openssh-unix-dev at mindrot.org ## > configure: WARNING: ## ------------------------------------------- ## > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev Have you checked config.log for any details? What OS is this on? What is your environment like; specicically CC, CFLAGS, etc? -- Iain Morgan From vinschen at redhat.com Tue Mar 27 18:43:47 2012 From: vinschen at redhat.com (Corinna Vinschen) Date: Tue, 27 Mar 2012 09:43:47 +0200 Subject: [PATCH/cygwin]: Explicitely undefine _WIN32 In-Reply-To: <20120319092843.GN19107@calimero.vinschen.de> References: <20120316215150.GE19107@calimero.vinschen.de> <20120317024713.19694.qmail@stuge.se> <20120317101021.GF19107@calimero.vinschen.de> <20120319092843.GN19107@calimero.vinschen.de> Message-ID: <20120327074347.GA27938@calimero.vinschen.de> On Mar 19 10:28, Corinna Vinschen wrote: > On Mar 17 09:07, Glenn Maynard wrote: > > On Sat, Mar 17, 2012 at 5:10 AM, Corinna Vinschen wrote: > > > > > +/* Make sure _WIN32 isn't defined later in the code, otherwise headers > > > from > > > + other packages might get the wrong idea about the target system. */ > > > +#ifdef _WIN32 > > > +#undef _WIN32 > > > +#endif > > > > > > > #undef for an undefined macro should be a no-op, so the #ifdef should be > > unnecessary. > > You're right. BUt it looks cleaner, doesn't it? Anyway, whoever has > checkin rights, please apply any one of the patches you like better. Ping? Could this please be applied for 6.0 so that I can release a Kerberos-enabled version in the Cygwin distro? Thanks, Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From garey.mills at gmail.com Wed Mar 28 03:34:51 2012 From: garey.mills at gmail.com (garey) Date: Tue, 27 Mar 2012 09:34:51 -0700 (PDT) Subject: problem with setting up ssh chroot account Message-ID: <981a9faa-2eb5-4d7d-942d-f0ef995a4984@qg3g2000pbc.googlegroups.com> Hello - I am trying to set up a ssh chroot account on a Red Hat Enterprise Linux 5 server. I have my jail set up and have copied over a selection of commands and their libraries. I have also created a / dev and some devices. As part of that, I had to create a /dev/pts directory to handle the terminals. However, when I try to connect as the chrooted user, I get the following error: error: /dev/pts/0: No such file or directory Does anyone know how to solve this problem? Garey Mills From des at des.no Wed Mar 28 04:46:17 2012 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Tue, 27 Mar 2012 19:46:17 +0200 Subject: problem with setting up ssh chroot account In-Reply-To: <981a9faa-2eb5-4d7d-942d-f0ef995a4984@qg3g2000pbc.googlegroups.com> (garey's message of "Tue, 27 Mar 2012 09:34:51 -0700 (PDT)") References: <981a9faa-2eb5-4d7d-942d-f0ef995a4984@qg3g2000pbc.googlegroups.com> Message-ID: <86boni0weu.fsf@ds4.des.no> garey writes: > I am trying to set up a ssh chroot account on a Red Hat Enterprise > Linux 5 server. I have my jail set up and have copied over a selection > of commands and their libraries. I have also created a / dev and some > devices. As part of that, I had to create a /dev/pts directory to > handle the terminals. > > However, when I try to connect as the chrooted user, I get the > following error: > > error: /dev/pts/0: No such file or directory > > Does anyone know how to solve this problem? /dev/pts is not a regular directory, it's a mountpoint for the synthetic devpts filesystem. You need to mount a devpts instance inside the chroot: # mkdir /chroot/dev/pts # mount -t devpts devpts /chroot/dev/pts DES -- Dag-Erling Sm?rgrav - des at des.no From garey.mills at gmail.com Wed Mar 28 04:53:37 2012 From: garey.mills at gmail.com (Garey Mills) Date: Tue, 27 Mar 2012 10:53:37 -0700 Subject: problem with setting up ssh chroot account In-Reply-To: <86boni0weu.fsf@ds4.des.no> References: <981a9faa-2eb5-4d7d-942d-f0ef995a4984@qg3g2000pbc.googlegroups.com> <86boni0weu.fsf@ds4.des.no> Message-ID: Dag-Erling - Thanks for the response. Definitely changed the error message. Now I'm getting Mar 27 11:34:52 dlab-gis sshd[11121]: error: open /dev/tty failed - could not set controlling tty: Permission denied Any thoughts? Garey Mills On Tue, Mar 27, 2012 at 10:46 AM, Dag-Erling Sm?rgrav wrote: > garey writes: > > I am trying to set up a ssh chroot account on a Red Hat Enterprise > > Linux 5 server. I have my jail set up and have copied over a selection > > of commands and their libraries. I have also created a / dev and some > > devices. As part of that, I had to create a /dev/pts directory to > > handle the terminals. > > > > However, when I try to connect as the chrooted user, I get the > > following error: > > > > error: /dev/pts/0: No such file or directory > > > > Does anyone know how to solve this problem? > > /dev/pts is not a regular directory, it's a mountpoint for the synthetic > devpts filesystem. You need to mount a devpts instance inside the > chroot: > > # mkdir /chroot/dev/pts > # mount -t devpts devpts /chroot/dev/pts > > DES > -- > Dag-Erling Sm?rgrav - des at des.no > -- The brain is not where you think. Me From keisial at gmail.com Wed Mar 28 07:28:21 2012 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Tue, 27 Mar 2012 22:28:21 +0200 Subject: problem with setting up ssh chroot account In-Reply-To: References: <981a9faa-2eb5-4d7d-942d-f0ef995a4984@qg3g2000pbc.googlegroups.com> <86boni0weu.fsf@ds4.des.no> Message-ID: <4F7222E5.4010109@gmail.com> On 27/03/12 19:53, Garey Mills wrote: > Dag-Erling - > > Thanks for the response. Definitely changed the error message. Now I'm > getting > > Mar 27 11:34:52 dlab-gis sshd[11121]: error: open /dev/tty > failed - could not set controlling tty: Permission denied > > Any thoughts? > > Garey Mills Well, what are the permissions of the /dev/tty device inside the chroot? Is it indeed a character device with major number 5 and minor 0? It is supposed to link the process with its controlling terminal. From garey.mills at gmail.com Wed Mar 28 07:41:31 2012 From: garey.mills at gmail.com (Garey Mills) Date: Tue, 27 Mar 2012 13:41:31 -0700 Subject: problem with setting up ssh chroot account In-Reply-To: <4F7222E5.4010109@gmail.com> References: <981a9faa-2eb5-4d7d-942d-f0ef995a4984@qg3g2000pbc.googlegroups.com> <86boni0weu.fsf@ds4.des.no> <4F7222E5.4010109@gmail.com> Message-ID: On Tue, Mar 27, 2012 at 1:28 PM, ?ngel Gonz?lez wrote: > On 27/03/12 19:53, Garey Mills wrote: > > Dag-Erling - > > > > Thanks for the response. Definitely changed the error message. Now > I'm > > getting > > > > Mar 27 11:34:52 dlab-gis sshd[11121]: error: open /dev/tty > > failed - could not set controlling tty: Permission denied > > > > Any thoughts? > > > > Garey Mills > Well, what are the permissions of the /dev/tty device inside the chroot? > Is it indeed a character device with major number 5 and minor 0? > > It is supposed to link the process with its controlling terminal. > > crw-rw-rw-. 1 root root 5, 0 Mar 19 14:29 tty -- The brain is not where you think. Me From calestyo at scientia.net Wed Mar 28 09:17:51 2012 From: calestyo at scientia.net (Christoph Anton Mitterer) Date: Wed, 28 Mar 2012 00:17:51 +0200 Subject: how to speed up OpenSSH command execution (and a speed analysis) In-Reply-To: <4F6F8DAF.9030805@gmail.com> References: <7fc6cf717a19d227d08de9970cf6a77d@scientia.net> <20120325173239.GA767@apb-laptoy.apb.alt.za> <1332705090.3434.52.camel@fermat.scientia.net> <4F6F8DAF.9030805@gmail.com> Message-ID: <1332886671.3438.45.camel@fermat.scientia.net> Hi. I digged a bit deeper... On Sun, 2012-03-25 at 23:27 +0200, ?ngel Gonz?lez wrote: > Maybe your nrpe command behaves differently if it is run with a > pseudo-terminal ? It's not the command on the other side... it's actually SSH... (though I still don't know why). Find attached several time measurement logs. The 1st column is always the real time from bash's builtin version of time (which is a bit different from the time binary). The 2nd column is what ssh -V gives on the respective remote host. The 3rd column is just the name of the remote host. The output is sorted with sort (i.e. by the first column). ControlMaster was always auto . ControlPersist was always 1d . * RequestTTY_.log In those cases, a ~/.ssh/config contained RequestTTY . The first connection was started WITHOUT "-t". Then the measurements were done in subsequent connections (I always made several and the values were then basically the same). Afterwards I killed all multiplexer ssh processes. => As you can see, even without "-t" on the first connection, I get up to the 0.007s BUT only for ssh version > 5.x So something must have changed between 4.x and 5.x => I thought RequestTTY would correspond to -t ... but as I tried all the options for the former, and ssh versions 4.x got never as fast as 5.x ... there must be "more" behind -t. * no_RequestTTY_but_-t_set.log This is the same as above, except: ~/.ssh/config did NOT contain RequestTTY. The first connection was started WITH "-t". => As you see, this time,.. even 4.x versions become fast. Any ideas? Chris. -------------- next part -------------- A non-text attachment was scrubbed... Name: logs.tar.bz2 Type: application/x-bzip-compressed-tar Size: 1362 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5677 bytes Desc: not available URL: From garey.mills at gmail.com Wed Mar 28 10:02:29 2012 From: garey.mills at gmail.com (Garey Mills) Date: Tue, 27 Mar 2012 16:02:29 -0700 Subject: problem with setting up ssh chroot account In-Reply-To: References: <981a9faa-2eb5-4d7d-942d-f0ef995a4984@qg3g2000pbc.googlegroups.com> <86boni0weu.fsf@ds4.des.no> <4F7222E5.4010109@gmail.com> Message-ID: To keep the conversation going, here are listings of my chroot directory's dev and dev/pts directories and the listing of the OS's /dev/pts directory [root at dlab-gis dev]# ls -l total 0 crw-rw-rw-. 1 root root 1, 3 Mar 19 14:28 null drwxr-xr-x. 2 root root 0 Aug 17 2011 pts crw-rw-rw-. 1 root root 5, 0 Mar 19 14:29 tty crw-r--r--. 1 root root 1, 9 Mar 19 14:28 urandom crw-rw-rw-. 1 root root 1, 5 Mar 19 14:29 zero [root at dlab-gis dev]# cd pts [root at dlab-gis pts]# ls -l total 0 crw--w----. 1 gmills tty 136, 0 Mar 27 16:44 0 c---------. 1 root root 5, 2 Aug 17 2011 ptmx [root at dlab-gis pts]# ls /dev/pts 0 ptmx [root at dlab-gis pts]# ls -l /dev/pts total 0 crw--w----. 1 gmills tty 136, 0 Mar 27 16:45 0 c---------. 1 root root 5, 2 Aug 17 2011 ptmx The devpts partition is mounted at /dev/pts and /home/jail/dev/pts. Perhaps this is the problem? Garey Mills On Tue, Mar 27, 2012 at 1:41 PM, Garey Mills wrote: > > > On Tue, Mar 27, 2012 at 1:28 PM, ?ngel Gonz?lez wrote: > >> On 27/03/12 19:53, Garey Mills wrote: >> > Dag-Erling - >> > >> > Thanks for the response. Definitely changed the error message. Now >> I'm >> > getting >> > >> > Mar 27 11:34:52 dlab-gis sshd[11121]: error: open /dev/tty >> > failed - could not set controlling tty: Permission denied >> > >> > Any thoughts? >> > >> > Garey Mills >> Well, what are the permissions of the /dev/tty device inside the chroot? >> Is it indeed a character device with major number 5 and minor 0? >> >> It is supposed to link the process with its controlling terminal. >> >> > crw-rw-rw-. 1 root root 5, 0 Mar 19 14:29 tty > > > -- > The brain is not where you think. > Me > > -- The brain is not where you think. Me From Nick.Williams at morganstanley.com Wed Mar 28 23:01:51 2012 From: Nick.Williams at morganstanley.com (Williams, Nick) Date: Wed, 28 Mar 2012 13:01:51 +0100 Subject: patch for OSX Message-ID: Attached is a patch to make sshd work on OSX when using plain ol' Kerberos authentication as opposed to opendirectory authentication. Cheers, Nick -------------------------------------------------------------------------- NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions or views contained herein are not intended to be, and do not constitute, advice within the meaning of Section 975 of the Dodd-Frank Wall Street Reform and Consumer Protection Act. If you have received this communication in error, please destroy all electronic and paper copies and notify the sender immediately. Mistransmission is not intended to waive confidentiality or privilege. Morgan Stanley reserves the right, to the extent permitted under applicable law, to monitor electronic communications. This message is subject to terms available at the following link: http://www.morganstanley.com/disclaimers. If you cannot access these links, please notify us by reply message and we will send the contents to you. By messaging with Morgan Stanley you consent to the foregoing. From lukasz.bienczyk at gmail.com Thu Mar 29 04:04:27 2012 From: lukasz.bienczyk at gmail.com (=?ISO-8859-2?Q?=A3ukasz_Bie=F1czyk?=) Date: Wed, 28 Mar 2012 19:04:27 +0200 Subject: socket buffer size Message-ID: Hello What do you think about adding options to ssh_config and sshd_config which will change receive and send buffer(SO_RCVBUF/SO_SNDBUF). I really care of it and I could prepare such a patch, would you accept it? -- lukasz From slovichon at gmail.com Fri Mar 30 10:01:56 2012 From: slovichon at gmail.com (Jared Yanovich) Date: Thu, 29 Mar 2012 19:01:56 -0400 Subject: percent_expand for QoS in ControlPath Message-ID: <20120329230156.GW31468@nightderanger.bender.mtx> Hi, Not sure if this anyone else is interested in this but to me it seems to make sense to use different control session multiplexer sockets for bulk and interactive workloads. Index: auth.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/auth.c,v retrieving revision 1.94 diff -u -p -r1.94 auth.c --- auth.c 23 May 2011 03:33:38 -0000 1.94 +++ auth.c 29 Mar 2012 23:00:06 -0000 @@ -326,7 +326,7 @@ check_key_in_hostfiles(struct passwd *pw * * XXX Should any specific check be done for sym links ? * - * Takes an open file descriptor, the file name, a uid and and + * Takes an open file descriptor, the file name, a uid and an * error buffer plus max size as arguments. * * Returns 0 on success and -1 on failure Index: ssh.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/ssh.c,v retrieving revision 1.368 diff -u -p -r1.368 ssh.c --- ssh.c 24 Oct 2011 02:10:46 -0000 1.368 +++ ssh.c 29 Mar 2012 23:00:06 -0000 @@ -701,7 +701,7 @@ main(int ac, char **av) options.port = sp ? ntohs(sp->s_port) : SSH_DEFAULT_PORT; } - /* preserve host name given on command line for %n expansion */ + /* preserve host name given on command line for %h expansion */ host_arg = host; if (options.hostname != NULL) { host = percent_expand(options.hostname, @@ -750,6 +750,8 @@ main(int ac, char **av) options.control_path = percent_expand(cp, "h", host, "l", thishost, "n", host_arg, "r", options.user, "p", portstr, "u", pw->pw_name, "L", shorthost, + "Q", iptos2str(tty_flag ? + options.ip_qos_interactive : options.ip_qos_bulk), (char *)NULL); xfree(cp); } Index: ssh_config.5 =================================================================== RCS file: /cvs/src/usr.bin/ssh/ssh_config.5,v retrieving revision 1.154 diff -u -p -r1.154 ssh_config.5 --- ssh_config.5 9 Sep 2011 00:43:00 -0000 1.154 +++ ssh_config.5 29 Mar 2012 23:00:06 -0000 @@ -313,23 +313,30 @@ in the section above or the string .Dq none to disable connection sharing. -In the path, -.Ql %L -will be substituted by the first component of the local host name, -.Ql %l -will be substituted by the local host name (including any domain name), -.Ql %h -will be substituted by the target host name, -.Ql %n -will be substituted by the original target host name -specified on the command line, -.Ql %p -the port, -.Ql %r -by the remote login username, and -.Ql %u -by the username of the user running -.Xr ssh 1 . +.Pp +In the path, the following substitutions are recognized: +.Pp +.Bl -tag -width 3n -compact -offset 2n +.It \&%h +target host name +.It \&%L +first component of the local host name +.It \&%l +local host name (including any domain name) +.It \&%n +original target host name specified on the command line +.It \&%p +port +.It \&%Q +quality of service string +.Pq e.g. Dq lowdelay +.It \&%r +remote login username +.It \&%u +username of the user running +.Xr ssh 1 +.El +.Pp It is recommended that any .Cm ControlPath used for opportunistic connection sharing include From dtucker at zip.com.au Fri Mar 30 11:59:07 2012 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 30 Mar 2012 11:59:07 +1100 Subject: patch for OSX In-Reply-To: References: Message-ID: <20120330005907.GA5787@gate.dtucker.net> On Wed, Mar 28, 2012 at 01:01:51PM +0100, Williams, Nick wrote: > Attached is a patch to make sshd work on OSX when using plain ol' > Kerberos authentication as opposed to opendirectory authentication. Unfortunately your diff didn't make it to the list (it strips any attachments that aren't plain text). Please resend as text or inline, or open a bug at https://bugzilla.mindrot.org and attach it there. Thanks. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From djm at mindrot.org Fri Mar 30 14:07:27 2012 From: djm at mindrot.org (Damien Miller) Date: Fri, 30 Mar 2012 14:07:27 +1100 (EST) Subject: [PATCH/cygwin]: Explicitely undefine _WIN32 In-Reply-To: <20120327074347.GA27938@calimero.vinschen.de> References: <20120316215150.GE19107@calimero.vinschen.de> <20120317024713.19694.qmail@stuge.se> <20120317101021.GF19107@calimero.vinschen.de> <20120319092843.GN19107@calimero.vinschen.de> <20120327074347.GA27938@calimero.vinschen.de> Message-ID: On Tue, 27 Mar 2012, Corinna Vinschen wrote: > Ping? Could this please be applied for 6.0 so that I can release a > Kerberos-enabled version in the Cygwin distro? Applied - thanks From saku at ytti.fi Fri Mar 30 17:25:10 2012 From: saku at ytti.fi (Saku Ytti) Date: Fri, 30 Mar 2012 09:25:10 +0300 Subject: percent_expand for QoS in ControlPath In-Reply-To: <20120329230156.GW31468@nightderanger.bender.mtx> References: <20120329230156.GW31468@nightderanger.bender.mtx> Message-ID: I'm not sure if I understand what is suggested here, but I think it might be that in ControlMaster scenario some packets would be sent with different TOS value than another. But I don't think it actually matters, consider you're having interactive ssh session to remote host from your PC behind ADSL, all good. Then you upload large file from your PC to the same remote host. Now without ControlMaster all is well, with proper TOS values in packets, interactive session won't become laggy, but in ControlMaster it will. And I don't understand how it could be solved, as TCP guarantees at kernel level ordering of packets, so even if your ADSL CPE reorders the packets and sends the high priority interactive ssh packets first the remote host kernel will not give them to userland until original order has restored, essentially rendering the prioritization done in the ADSL CPE useless. (This is practical example of problem I run into weekly, I workaround it by setting ControlPath none for scp) On 30 March 2012 02:01, Jared Yanovich wrote: > Hi, > > Not sure if this anyone else is interested in this but to me it seems to make > sense to use different control session multiplexer sockets for bulk and > interactive workloads. > > Index: auth.c > =================================================================== > RCS file: /cvs/src/usr.bin/ssh/auth.c,v > retrieving revision 1.94 > diff -u -p -r1.94 auth.c > --- auth.c ? ? ?23 May 2011 03:33:38 -0000 ? ? ?1.94 > +++ auth.c ? ? ?29 Mar 2012 23:00:06 -0000 > @@ -326,7 +326,7 @@ check_key_in_hostfiles(struct passwd *pw > ?* > ?* XXX Should any specific check be done for sym links ? > ?* > - * Takes an open file descriptor, the file name, a uid and and > + * Takes an open file descriptor, the file name, a uid and an > ?* error buffer plus max size as arguments. > ?* > ?* Returns 0 on success and -1 on failure > Index: ssh.c > =================================================================== > RCS file: /cvs/src/usr.bin/ssh/ssh.c,v > retrieving revision 1.368 > diff -u -p -r1.368 ssh.c > --- ssh.c ? ? ? 24 Oct 2011 02:10:46 -0000 ? ? ?1.368 > +++ ssh.c ? ? ? 29 Mar 2012 23:00:06 -0000 > @@ -701,7 +701,7 @@ main(int ac, char **av) > ? ? ? ? ? ? ? ?options.port = sp ? ntohs(sp->s_port) : SSH_DEFAULT_PORT; > ? ? ? ?} > > - ? ? ? /* preserve host name given on command line for %n expansion */ > + ? ? ? /* preserve host name given on command line for %h expansion */ > ? ? ? ?host_arg = host; > ? ? ? ?if (options.hostname != NULL) { > ? ? ? ? ? ? ? ?host = percent_expand(options.hostname, > @@ -750,6 +750,8 @@ main(int ac, char **av) > ? ? ? ? ? ? ? ?options.control_path = percent_expand(cp, "h", host, > ? ? ? ? ? ? ? ? ? ?"l", thishost, "n", host_arg, "r", options.user, > ? ? ? ? ? ? ? ? ? ?"p", portstr, "u", pw->pw_name, "L", shorthost, > + ? ? ? ? ? ? ? ? ? "Q", iptos2str(tty_flag ? > + ? ? ? ? ? ? ? ? ? ? options.ip_qos_interactive : options.ip_qos_bulk), > ? ? ? ? ? ? ? ? ? ?(char *)NULL); > ? ? ? ? ? ? ? ?xfree(cp); > ? ? ? ?} > Index: ssh_config.5 > =================================================================== > RCS file: /cvs/src/usr.bin/ssh/ssh_config.5,v > retrieving revision 1.154 > diff -u -p -r1.154 ssh_config.5 > --- ssh_config.5 ? ? ? ?9 Sep 2011 00:43:00 -0000 ? ? ? 1.154 > +++ ssh_config.5 ? ? ? ?29 Mar 2012 23:00:06 -0000 > @@ -313,23 +313,30 @@ in the > ?section above or the string > ?.Dq none > ?to disable connection sharing. > -In the path, > -.Ql %L > -will be substituted by the first component of the local host name, > -.Ql %l > -will be substituted by the local host name (including any domain name), > -.Ql %h > -will be substituted by the target host name, > -.Ql %n > -will be substituted by the original target host name > -specified on the command line, > -.Ql %p > -the port, > -.Ql %r > -by the remote login username, and > -.Ql %u > -by the username of the user running > -.Xr ssh 1 . > +.Pp > +In the path, the following substitutions are recognized: > +.Pp > +.Bl -tag -width 3n -compact -offset 2n > +.It \&%h > +target host name > +.It \&%L > +first component of the local host name > +.It \&%l > +local host name (including any domain name) > +.It \&%n > +original target host name specified on the command line > +.It \&%p > +port > +.It \&%Q > +quality of service string > +.Pq e.g. Dq lowdelay > +.It \&%r > +remote login username > +.It \&%u > +username of the user running > +.Xr ssh 1 > +.El > +.Pp > ?It is recommended that any > ?.Cm ControlPath > ?used for opportunistic connection sharing include > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev -- ? ++ytti From slovichon at gmail.com Fri Mar 30 18:22:20 2012 From: slovichon at gmail.com (Jared Yanovich) Date: Fri, 30 Mar 2012 03:22:20 -0400 Subject: percent_expand for QoS in ControlPath In-Reply-To: References: <20120329230156.GW31468@nightderanger.bender.mtx> Message-ID: <20120330072220.GJ31468@nightderanger.bender.mtx> On Fri, Mar 30, 2012 at 09:25:10AM +0300, Saku Ytti wrote: > packets, interactive session won't become laggy, but in ControlMaster > it will. And I don't understand how it could be solved, as TCP > guarantees at kernel level ordering of packets, so even if your ADSL > CPE reorders the packets and sends the high priority interactive ssh > packets first the remote host kernel will not give them to userland > until original order has restored, essentially rendering the > prioritization done in the ADSL CPE useless. That is why I suggested two separate sockets. This would mean ordering was maintained only down to the socket level, no? Host host ControlPath ~/.ssh/ctlsock/%h.%Q ---------------------------------------------------------------------- $ ssh host # this creates ~/.ssh/ctlsock/host.lowdelay $ scp file host: # this creates ~/.ssh/ctlsock/host.throughput All subsequent bulk transfers will use the 'throughput' socket, and likewise for interactive to 'lowdelay'. Am I mistaken? From saku at ytti.fi Fri Mar 30 18:28:00 2012 From: saku at ytti.fi (Saku Ytti) Date: Fri, 30 Mar 2012 10:28:00 +0300 Subject: percent_expand for QoS in ControlPath In-Reply-To: <20120330072220.GJ31468@nightderanger.bender.mtx> References: <20120329230156.GW31468@nightderanger.bender.mtx> <20120330072220.GJ31468@nightderanger.bender.mtx> Message-ID: On 30 March 2012 10:22, Jared Yanovich wrote: > That is why I suggested two separate sockets. > > This would mean ordering was maintained only down to the socket level, no? > > ?Host host > ? ?ControlPath ~/.ssh/ctlsock/%h.%Q > ---------------------------------------------------------------------- > ?$ ssh host ? ? ? ? ? ?# this creates ~/.ssh/ctlsock/host.lowdelay > ?$ scp file host: ? ? ?# this creates ~/.ssh/ctlsock/host.throughput > > All subsequent bulk transfers will use the 'throughput' socket, and likewise for > interactive to 'lowdelay'. > > Am I mistaken? If it transits with different TCP ports, it'll work, if it transits in same TCP port, I don't understand how it could work, but I'd love to see it done. If it's different TCP ports, you're losing benefits of the ControlSocket, as you need to do new 3way handshake etc (or multiple, if that SSH connection happens to traverse many devices)? -- ? ++ytti From slovichon at gmail.com Fri Mar 30 20:47:16 2012 From: slovichon at gmail.com (Jared Yanovich) Date: Fri, 30 Mar 2012 05:47:16 -0400 Subject: percent_expand for QoS in ControlPath In-Reply-To: References: <20120329230156.GW31468@nightderanger.bender.mtx> <20120330072220.GJ31468@nightderanger.bender.mtx> Message-ID: <20120330094716.GK31468@nightderanger.bender.mtx> On Fri, Mar 30, 2012 at 10:28:00AM +0300, Saku Ytti wrote: > > That is why I suggested two separate sockets. > > If it's different TCP ports, you're losing benefits of the > ControlSocket, as you need to do new 3way handshake etc (or multiple, > if that SSH connection happens to traverse many devices)? Yes, it's not perfect. It is a compromise between occasionally laggy interactive sessions and entirely abandoning ControlPath, as well as hacking the command line options to achieve a similar effect. And it's optional to use. Some may consider it feature creep; I don't know. Just sharing for any one else that may benefit from its use.