Update FreeBSD 7.2 to 8.4 now sshd can't find libcrypto.so.6

S

sintheaus

I am updating a legacy FreeBSD 7.4-RELEASE system to 8.4-RELEASE (hey, better late then never!) using freebsd-update.

I followed the instructions at https://www.freebsd.org/releases/8.4R/installation.html , and did the following:
  1. freebsd-update upgrade -r 8.4-RELEASE
  2. merge many files
  3. Update system and reboot to load new kernel: freebsd-update install , followed by shutdown -r now
  4. Update userland components, using: freebsd-update install & reboot again.
  5. And then I was going to update all ports on my system. But I never made it this far because I can't ssh into the system.
Now, sshd won't start, because libcrypto.so.6 can't be found. I logged into the console and saw errors like these:

Code: 
host# /etc/rc.d/sshd restart
You already have an RSA host key in /etc/ssh/ssh_host_key
Skipping protocol version 1 RSA Key Generation
You already have a DSA host key in /etc/ssh/ssh_host_dsa_key
Skipping protocol version 2 DSA Key Generation
You already have an RSA host key in /etc/ssh/ssh_host_rsa_key
Skipping protocol version 2 RSA Key Generation
/libexec/ld-elf.so.1: Shared object "libcrypto.so.6" not found, required by "ssh-keygen"
Performing sanity check on sshd configuration.
/libexec/ld-elf.so.1: Shared object "libcrypto.so.6" not found, required by "sshd"
/etc/rc.d/sshd: WARNING: failed precmd routine for sshd

ssh isn't the only thing broken. Other utilities such as portsnap fail because it too cannot find libcrypto.so.6, pkg_info fails because it can't find libssl.so.6.

How can I restore the missing libraries? I see /lib/libcrypto.so.5 but not libcrypto.so.6.

I do not use OpenSSL from ports. I only use OpenSSL from the base system.
 
Re: Update FreeBSD 7.2 to 8.4 now sshd can't find libcrypto.

Are you able to use the single user console? You could try freebsd-update rollback. Then try and update to the very latest of 7.2 and try the update to 8.4 again.
 
Re: Update FreeBSD 7.2 to 8.4 now sshd can't find libcrypto.

freebsd-update rollback worked. At least I now have a functional system.

This happened because freebsd-update asked me to merge 100 files, and somewhere along the line I made a mistake and freebsd-update proceeded with a corrupt file.

Thanks.
 
i really don't like the fact they hacked SSH and PAM into all old software (i.e. rsh). Now e.g. in.pop3d won't work.

i'm an all or none kinda person. block all outside access / use of services (i have to, my isp blocks them and extorts me to turn them back on). Secure all on the wire or nothing, assume it's insecure. Secure the whole line, not each app on the line. Unix is more useful when free of hinderences and complexity where it isn't needed at all (can you tell i'm no security freak?) and security should be outside an app and work with any app, not inside and hindering use and compiling.

i hate when i can't use login and need extra libraries when compiling very simple software. i at times love using old (bsd) software. Something easy to hack a few changes i need locally that a billion lines of XML config preparedness code couldn't match up to: what i need, and soon, locally.

On the other hand i've used tunnel security - and toyed with inet wrappers. Why have several apps you can't control hacked into all your software? Why not wrap them all with one wrapper? You see? Should each web page have its own Java sshd inside in the HTML page? Or use certificates outside? Having SSH in each i worry about so many having IP security randomly i can't check what each app might be doing.

Look: if it really is secure, it means if they root you, you can't tell they are on your machine, since it's all buried and hidden you won't know. You see? Or don't you see?

i really think the old way was simpler and better.

And really? Most people are trying to get their word out to the world, not prevent others from seeing them :)

And SSH has been know to mess with X (SSH is inside your packets and actually deletes parts in them at times) and it will also be clear text after install. (Key generated after install? snif your lan wire and then tell me it's secure upon install, please.) And PAM? It might be secure, i don't know, i'm still reading a thud and thing about what i missed (i must have something: it's not like i can do ls -la and see who owns it, it's not that simple now, I wish it still were).

You know you line is prolly already secure (your modem) from simple tampering. But you know, that's just me. i think they should have left all the hacking in of SSH, PAM and even tcp support of all apps: as module, optional if your asking for it.

And it pays not to ask for too much. And you should only get into the trouble you're asking for :)
 
Sniff your LAN after install. when i did i had keys and all: line was plain text. i read sshd setup (on debian NOT bsd). yup - i was right, it made a default key which leaves NO line security, only to root are things obscure on lan it's clear text. and to get it the other way around: hours of reading and carfully configuring a comlplex thing: on mistake and it's all for naught. and if there are any back doors in ssh, all for naught.

my favorite was redhat telling all use X --no-tcp. when i tested it i had tcp access to the pc on the lan from ALL computers EXCEPT the one it was running on (read the code, code is clear and easy to read and unchange for years: it shuts off localhost access not remote). you can run X by socket "no tcp" (but now a file/sock to secure). but to run X fully network aware (ie, remote desktop or what) you need to log in using your host IP. so secure the host, --no-tcp isn't a good sol'n for you.
 
Now, sshd won't start, because libcrypto.so.6 can't be found ?

Well either your install stopped and started using sshd before it got installed (it shouldn't) or something went wrong.

Reinstall sshd. it SHOULD install libcrypto first UNLESS it's part of base (which i bet it is, in /lib).

If it's part of base that's special: i.ee, if your installing broken libraries (replace old with incompatible new) then old software can use new libraries, old library was removed to replace, and this is one reason why BSD has a clean base install free of "portage dependency". it has a clean 1-2-3 order to do things.

Really: a minor library version should always work with both old and new software, and major libraries should never prevent old libraries from working (i.ee, Sun Microsystems library design).

Ok, if libcrypto is portage not base then it should be higher in dependency order than sshd and be a strong depends. Now remember you have a world of hacked software designed to take a dump if sshd isn't working (^^^ didn't i tell you above). So when you edit your portage template for depends make sure libcrypto is before sshd but that it all happens without ever removing what is working.

If not, you can live on the edge and install from a shell a quick switcheroo (ridiculous, since it's a minor library change - harummmf!). Your old library is still in memory until you exit shell: NOTE you only get one chance to get it right or need to re-install from scratch! Or, perhaps since your kernel could care less which root it uses and sshd isn't in the kernel (god i hope not, not yet). You can run from a chroot or jail while having access to the base you are installing.

Now if you're lucky sshd is in your boot loader and you won't be able to enter your boot password either, due to same library name but that are incompatible, upon a binary that is deeply seated in futile runtime dependencies!
 
You must log in or register to reply here.
Back
Top