openssh static build - mission impossible?

Nico Kadel-Garcia nkadel at gmail.com
Mon Mar 12 03:09:01 EST 2012


On Sun, Mar 11, 2012 at 11:15 AM, Mr Dash Four
<mr.dash.four at googlemail.com>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
> <EOF>
>
> 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<https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev>
>


More information about the openssh-unix-dev mailing list