Hi, The LIBS="-lcrypt" workaround is known bug, it will be fixed in the next release.
The other problems with compiling statically are more general. It isn't really possible to compile a program totally statically against glibc since it will still depend on dynamic libnss*.so depending on the contents of /etc/nsswitch.conf. That's what the warning about "initgroups" etc means. My advice would be to build statically against uClibc which is well tested with Dropbear. The LIBS="-lcrypt" will still be needed for the time being. Cheers, Matt On Sun, Oct 16, 2011 at 01:50:59PM +0000, Tilman Glotzner wrote: > > Hello > > > I am trying to compile dropbrear statically: > > 1) configure > LDFLAGS="-L/opt/nfs/vmic7750/usr/lib/ -L/opt/nfs/vmic7750/lib/" ./configure > --prefix=/opt/nfs/vmic7750/usr --with-zlib=/opt/nfs/vmic7750/usr/lib/ > > 2) STATIC=1 LDFLAGS="-L/opt/nfs/vmic7750/usr/lib/ -L/opt/nfs/vmic7750/lib/" > make PROGRAMS="dropbear dropbearkey scp" > This results in an error: > > gcc -L/opt/nfs/vmic7750/usr/lib/ -L/opt/nfs/vmic7750/usr/lib/ > -L/opt/nfs/vmic7750/lib/ -static -o dropbear dbutil.o buffer.o dss.o bignum.o > signkey.o rsa.o random.o queue.o atomicio.o compat.o fake-rfc2553.o > common-session.o packet.o common-algo.o common-kex.o common-channel.o > common-chansession.o termcodes.o loginrec.o tcp-accept.o listener.o > process-packet.o common-runopts.o circbuffer.o -lcrypt svr-kex.o svr-algo.o > svr-auth.o sshpty.o svr-authpasswd.o svr-authpubkey.o svr-authpubkeyoptions.o > svr-session.o svr-service.o svr-chansession.o svr-runopts.o svr-agentfwd.o > svr-main.o svr-x11fwd.o svr-tcpfwd.o svr-authpam.o libtomcrypt/libtomcrypt.a > libtommath/libtommath.a -lutil -lz > svr-chansession.o: In function `execchild': > svr-chansession.c:(.text+0x4b8): warning: Using 'initgroups' in statically > linked applications requires at runtime the shared libraries from the glibc > version used for linking > sshpty.o: In function `pty_setowner': > sshpty.c:(.text+0x18): warning: Using 'getgrnam' in statically linked > applications requires at runtime the shared libraries from the glibc version > used for linking > common-session.o: In function `fill_passwd': > common-session.c:(.text+0x9f): warning: Using 'getpwnam' in statically linked > applications requires at runtime the shared libraries from the glibc version > used for linking > dbutil.o: In function `connect_remote': > dbutil.c:(.text+0x96f): warning: Using 'getaddrinfo' in statically linked > applications requires at runtime the shared libraries from the glibc version > used for linking > svr-authpasswd.o: In function `svr_auth_password': > svr-authpasswd.c:(.text+0x16): warning: Using 'getspnam' in statically linked > applications requires at runtime the shared libraries from the glibc version > used for linking > svr-authpasswd.c:(.text+0x70): undefined reference to `crypt' > collect2: ld returned 1 exit status > make: *** [dropbear] Error 1 > > > 3) Next attempt: add LIBS="-lcrypt" > STATIC=1 LDFLAGS="-L/opt/nfs/vmic7750/usr/lib/ -L/opt/nfs/vmic7750/lib/" > LIBS="-lcrypt" make PROGRAMS="dropbear dropbearkey scp" > > This links with a couple of warnings: Most noticable one: > > gcc -L/opt/nfs/vmic7750/usr/lib/ -L/opt/nfs/vmic7750/usr/lib/ > -L/opt/nfs/vmic7750/lib/ -static -o scp scp.o progressmeter.o atomicio.o > scpmisc.o compat.o > scp.o: In function `main': > scp.c:(.text+0x2092): warning: Using 'getpwuid' in statically linked > applications requires at runtime the shared libraries from the glibc version > used for linking > > 4) dropbearkey is not portable > dropbearkey -t rsa -f /opt/nfs/vmic7750/etc/dropbear/dropbear_rsa_host_key > works on the machine on which I compiled it. > > On another machine, it however does not start. Error message is this: > dropbearkey -t rsa -f /etc/dropbear/dropbear_rsa_host_key > dropbearkey: /lib/libc.so.6: version `GLIBC_2.7' not found (required by > dropbear) > > I guess this is related to different libc's, i.e. the machine that compiled > dropbear probably uses an newer version than the one executing it. > Unfortunatelly, I do not get libc compiled. And I also wonder a bit, because > I hoped to avoid mismatches like this by statically linking. > > 5) I created dropbear_[rsa|dss]_host_key on the build machine, and copied to > the machine on which I want to run dropbear. /usr/sbin/dropbear starts up > fine. A root login is refused however: > > ssh [email protected] > .... > The authenticity of host '192.168.1.40 (192.168.1.40)' can't be established. > .... > Warning: Permanently added '192.168.1.40' (RSA) to the list of known hosts. > [email protected]'s password: > Permission denied, please try again. > ... > > Apparantly, dropbear does not know user root -- I wonder why however (root is > defined in /etc/passwd) : > > Oct 16 17:01:30 192.168.1.40 dropbear[867]: Child connection from > 192.168.1.59:44549 > Oct 16 17:01:31 192.168.1.40 dropbear[867]: Login attempt for nonexistent > user from 192.168.1.59:44549 > Oct 16 17:01:32 192.168.1.40 dropbear[867]: Login attempt for nonexistent > user from 192.168.1.59:44549 > Oct 16 17:01:33 192.168.1.40 dropbear[867]: Login attempt for nonexistent > user from 192.168.1.59:44549 > Oct 16 17:01:34 192.168.1.40 dropbear[867]: Login attempt for nonexistent > user from 192.168.1.59:44549 > Oct 16 17:01:35 192.168.1.40 dropbear[867]: Exit before auth: Error writing > > Help is certainly apprecitated .-) > > Thanks > > Tilman > > Thanks > > Tilman > > > > >
