Closed GoogleCodeExporter closed 8 years ago
Can you try if
http://shellinabox.googlecode.com/files/shellinabox_2.9(rev149)-1_i386.deb
works for
you? If so, then there probably is a subtle incompatibility with different
versions
of the SSL libraries on Debian. That might mean, I either have to find a
different
build machine, or I need to stop building Debian packages.
This version package file is just a snapshot of the SVN tree that I built using
a
Debian Lenny Live CD. It obviously installs fine on Lenny, but not sure whether
it
installs on all other commonly used Debian-based distributions. Also, building
under
qemu in the Live CD is super slow. So, that's not really a great long-term
solution.
The problem that you were seeing was probably caused by the fact that
shellinaboxd
will tried to load libssl, but couldn't do so and it then disabled all SSL
support.
You can tell that this happened, if you run "shellinaboxd --help" and there is
no
mention of any SSL commands (e.g. the "-t" command line option is missing).
Original comment by zod...@gmail.com
on 13 Jul 2009 at 8:07
Hi again! Sure, I'll try r149 and let you know how that works.
In the meantime, i've found the following:
ldd /usr/bin/shellinaboxd
linux-gate.so.1 => (0xffffe000)
libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7ecf000)
libutil.so.1 => /lib/tls/i686/cmov/libutil.so.1 (0xb7ecb000)
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7d9a000)
/lib/ld-linux.so.2 (0xb7eed000)
As you can see, there's no mention of the ELF binary being linked to the libssl
library. Does that mean that the library isn't where the program expects it to
be,
or that the Debian binary wasn't compiled with SSL support?
BTW, I'm not sure if this can be helpful, but here's the exact location of the
libssl files that get installed by the libssl0.9.8 package in Lenny (on the
i386
platform): http://packages.debian.org/lenny/i386/libssl0.9.8/filelist
Original comment by alejandr...@gmail.com
on 13 Jul 2009 at 2:54
Ok, i've just installed r149 on a Lenny box.
These are the differences that i can see comparing against the r139 package:
* When running ldd, another library is mentioned:
libz.so.1 => /usr/lib/libz.so.1 (0xb7f58000)
* The package now depends on libc6 >= 2.7-1, so it won't install on Etch
systems
(this is probably because of the ${shlibs:Depends} in the control file)
* When running shellinaboxd --help, the -t option is now mentioned
Anyway, when i start the daemon, SIAB creates a certificate.pem under /var/lib/
shellinabox, but still with zero length.
When i try to connect to http://localhost:4200, the browser gets redirected to
https
immediately, and then the connection fails.
I'll try to install the new package using the Lenny LiveCD and check if that
works.
Original comment by alejandr...@gmail.com
on 13 Jul 2009 at 3:26
Searching for libssl in the source code shows the following:
from ssl.c:
291: for (int i = 0; i < sizeof(symbols)/sizeof(symbols[0]); i++) {
if (!(*symbols[i].var = loadSymbol("libssl.so", symbols[i].fn))) {
debug("Failed to load SSL support. Could not find \"%s\"",
from debian/control:
11: Depends: ${shlibs:Depends}, adduser
Suggests: libssl0.9.8, libpam0g, openssl
But libssl.so is part of libssl-dev, which doesn't depend on openssl or
libssl0.9.8
(the same seems to be true for libcrypto.so, which is also part of libssl-dev
and is
referenced by the maybeLoadCrypto function).
Anyway, the system on which the previous test failed has libssl-dev installed,
and
both libcrypto.so and libssl.so are present under /usr/lib:
lrwxrwxrwx 1 root root 18 2009-04-23 03:56 /usr/lib/libcrypto.so ->
libcrypto.so.0.9.8
-rw-r--r-- 1 root root 1416548 2009-04-01 18:47 /usr/lib/libcrypto.so.0.9.8
lrwxrwxrwx 1 root root 15 2009-04-23 03:56 /usr/lib/libssl.so ->
libssl.so.0.9.8
-rw-r--r-- 1 root root 285156 2009-04-01 18:47 /usr/lib/libssl.so.0.9.8
Original comment by alejandr...@gmail.com
on 13 Jul 2009 at 3:50
Here are the results after installing r149 on a Lenny LiveCD (KDE version):
This LiveCD comes with openssl and libssl.0.9.8 packages installed, but it
doesn't
have libssl-dev. So there's no libssl.so under /usr/lib.
The new package can be installed without any problems, but if you run
shellinaboxd --
help, the "-t" option isn't there (which i guess is the expected behavior,
considering that there's no /usr/lib/libssl.so). The certificates aren't
created
under /var/lib/shellinabox, which i assume i also expected.
Ok, so i install libssl-dev, which has further dependencies, totalling 23.5 MB.
After installing libssl-dev and restarting shellinaboxd... SSL sessions started
working properly! If you access http://localhost:4200, the browser is
redirected
immediately to https, and after accepting the self-signed certificate, you have
an
encrypted connection.
Conclusions:
shellinaboxd works fine on Lenny. But... it needs some files that are provided
by
libssl-dev, which might no be installed on some systems.
I think that this could be solved by including a new explicit dependency in the
control file, so that if libssl-dev is not present, apt will let you know and
install it as needed. I don't know if this is a good practice according to the
Debian standards, but it would get the problem fixed until finding a more
elegant
solution.
Best regards,
Alex
Original comment by alejandr...@gmail.com
on 13 Jul 2009 at 11:27
I think, for the Debian package, I'll just disable the code that conditionally
loads
libssl.so and libpam.so, if they are available. Instead, I'll just make them
hard
dependencies.
The feature that dynamically decides whether the libraries are present is
useful for
sharing the same binary across multiple different machines. But that is a less
common
use case, if the binary was originally installed as package, instead of
compiled from
sources.
I checked that change into SVN, and it will be in the next release that I'll
make.
I hope that fixes this issue and I can continue offering Debian packages.
Thanks for
helping me track this down.
Original comment by zod...@gmail.com
on 13 Jul 2009 at 11:42
I'm glad that you could find a good solution to this problem.
I have to say that i'm really impressed by the quality of this product and as a
sysadmin i found it invaluable. So it's really good to know that there will be
more
Debian packages coming out!
If i can be of any further assistance in testing or troubleshooting
Debian-specific
issues, just let me know.
And thanks again for having made this contribution to the open source community.
Original comment by alejandr...@gmail.com
on 14 Jul 2009 at 3:37
Thank you for the kind words. This is the first time I have written any
non-trivial
amount of JavaScript, and it was a great way to learn the technology. Although
it did
turn out that writing a basic HTTP server in C was a somewhat larger part of the
project, too. In any case, I had and still have a lot of fun with the project,
and I
am glad to know that it is useful.
I asked Debian to officially include it in their repository, but who knows how
long
that will take. Without an official Debian maintainer sponsoring the project,
there
is not much I can do from my side:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=535905
I will definitely keep your offer in mind when I release the next Debian
package. I
always test on a couple of different machines, but the amount of test coverage
that I
can get by myself is obviously limited.
Original comment by zod...@gmail.com
on 14 Jul 2009 at 3:58
Original issue reported on code.google.com by
alejandr...@gmail.com
on 12 Jul 2009 at 9:19