6

Я не получаю no version information available при создании ssh .

Openssl verion:

sat:~# openssl version
OpenSSL 1.0.1f 6 Jan 2014

Вот вывод команды ldd /usr/bin/ssh:

/usr/bin/ssh: /usr/local/lib/libcrypto.so.1.0.0: no version information available (required by /usr/bin/ssh)
    linux-vdso.so.1 =>  (0x00007fff48bff000)
    libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007fdd57f1f000)
    libcrypto.so.1.0.0 => /usr/local/lib/libcrypto.so.1.0.0 (0x00007fdd57b3a000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fdd57935000)
    libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fdd5771e000)
    libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007fdd57508000)
    libgssapi_krb5.so.2 => /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2 (0x00007fdd572c8000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fdd56f3e000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fdd583b3000)
    libkrb5.so.3 => /usr/lib/x86_64-linux-gnu/libkrb5.so.3 (0x00007fdd56c6a000)
    libk5crypto.so.3 => /usr/lib/x86_64-linux-gnu/libk5crypto.so.3 (0x00007fdd56a40000)
    libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2 (0x00007fdd5683c000)
    libkrb5support.so.0 => /usr/lib/x86_64-linux-gnu/libkrb5support.so.0 (0x00007fdd56633000)
    libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1 (0x00007fdd5642e000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fdd56212000)

Вывод locate libcrypto.so.1.0.0:

sat:~# locate libcrypto.so.1.0.0
/usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
/usr/local/lib/libcrypto.so.1.0.0
/usr/src/openssl-1.0.1f/libcrypto.so.1.0.0

Как исправить эту ошибку?

Замечания:

Я скомпилировал и установил openssl . После этого я установил ssh через apt-get .

|источник

4 ответа4

8

Проблема: libssl.so.1.0.0 и libcrypto.so.1.0.0 Нет информации о версии. Предупреждение / ошибка.

После долгих исследований, времени и усилий (это заняло несколько недель), вот что я в итоге и сделал ...

В директории, где вы закончили извлекать исходный код для вашей версии openssl 1.0.1h (должен работать и для других версий). Я создаю файл с именем openssl.ld

В этом файле положить это ...

OPENSSL_1.0.0 {
    global:
    *;
};

сохрани это. Теперь введите ...

make clean

(Просто чтобы быть уверенным, что мы начинаем с нуля.)

Теперь для действительно ошеломляющей части ...

./config --prefix=/usr/local --openssldir=/usr/local/openssl shared -Wl,--version-script=openssl.ld -Wl,-Bsymbolic-functions

Затем...

make
make test
make install
ldconfig

И это должно сделать это. (Это так просто. Исправление не требуется.)

Я применил это решение к Debian Wheezy как в 32-, так и в 64-битной версиях. И сделали наблюдение. В 64-битной версии автоматически по умолчанию используются новые libssl.so.1.0.0 и libcrypto.so.1.0.0 , созданные в каталоге /usr/local/lib . 32-битная версия не делает. Вот почему я сначала подумал, что 32-битная версия Debian Wheezy не страдает от этой проблемы, но она возникает, когда вы получаете 32-битную версию, чтобы использовать новые библиотеки openssl в /usr/local/lib .

Использование команды ldd для проверки того, какие библиотеки используют бинарные файлы, также было неоценимым для понимания этого.

|источник
4

Я скомпилировал и установил openssl. После этого я установил ssh через apt-get.

Вероятно, это две разные версии OpenSSL. Вы, вероятно, будете в порядке, поскольку 1.0.0 двоично совместима с 1.0.1, 1.0.2 и т.д. (Однако, она не будет двоично совместима с 1.1.0).

Ваш ssh , вероятно, использует версию OpenSSL в /usr/lib/x86_64-linux-gnu/ . Вы должны использовать LD_PRELOAD чтобы убедиться, что ваша версия OpenSSL используется (конечно, при условии бинарной совместимости).

Если вы не хотите использовать LD_PRELOAD и друзей, то соберите ssh из исходников. Обязательно укажите rpath чтобы редактор ссылок использовал вашу версию OpenSSL, а не версию системы. То есть ваши LDFLAGS должны включать что-то вроде -Wl,-rpath,<path to your openssl> . Это в дополнение к обычным -lcrypto , -lssl и -L<path to your openssl> .

Если вы работаете в Mac OS X, имейте в виду , что параметры компоновщика, такие как -Bstatic и -rpath , игнорируются. Вы столкнетесь с таинственными сбоями из-за несовместимых двоичных файлов, потому что OS X предоставляет 0.9.8.

информация о версии недоступна

Что касается информации о версии, я понятия не имею. ssh может использовать либо OPENSSL_VERSION_NUMBER во время компиляции, либо SSLeay/SSLeay_version во время выполнения. Подробности смотрите в OPENSSL_VERSION_NUMBER(3) .

Как исправить эту ошибку?

Возможно, я что-то неправильно понимаю, но нигде в сообщении я не вижу ошибки.

|источник
0

Если вы хотите установить скомпилированные библиотеки, не ломайте свою систему, устанавливая префиксы /usr/local , /usr или / . Например, Debian/Ubuntu будет выбирать пользовательские библиотеки в /usr/local/lib при следующем ldconfig потому что он обычно указан в /etc/ld.so.conf.d/libc.conf .

Вот одноразовая коробка с openssl 1.0.2e, make install 'ed в --prefix=/usr/local и затем запустите ldconfig (без аргументов, который обновляет /etc/ld.so.cache):

# ldconfig -p | egrep 'lib(crypt|ssl)'
libssl.so.1.0.0 (libc6,x86-64) => /usr/local/lib/libssl.so.1.0.0
libssl.so.1.0.0 (libc6,x86-64) => /lib/x86_64-linux-gnu/libssl.so.1.0.0
libssl.so (libc6,x86-64) => /usr/local/lib/libssl.so
libssl.so (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libssl.so
libcrypto.so.1.0.0 (libc6,x86-64) => /usr/local/lib/libcrypto.so.1.0.0
libcrypto.so.1.0.0 (libc6,x86-64) => /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
libcrypto.so (libc6,x86-64) => /usr/local/lib/libcrypto.so
libcrypto.so (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libcrypto.so
libcrypt.so.1 (libc6,x32, OS ABI: Linux 3.4.0) => /libx32/libcrypt.so.1
libcrypt.so.1 (libc6,x86-64, OS ABI: Linux 2.6.24) => /lib/x86_64-linux-gnu/libcrypt.so.1
libcrypt.so.1 (libc6, OS ABI: Linux 2.6.24) => /lib32/libcrypt.so.1
libcrypt.so (libc6,x32, OS ABI: Linux 3.4.0) => /usr/libx32/libcrypt.so
libcrypt.so (libc6,x86-64, OS ABI: Linux 2.6.24) => /usr/lib/x86_64-linux-gnu/libcrypt.so
libcrypt.so (libc6, OS ABI: Linux 2.6.24) => /usr/lib32/libcrypt.so

Обратите внимание, как скомпилированные пользовательские файлы переопределяют библиотеки из пакета openssl .

Вместо этого, решение поставщику пользовательских библиотек и исполняемых файлов в изолированных каталогов , которые не зависят от ld.conf и PATH по умолчанию.

Установите программное обеспечение в /opt/$WHATEVER-$VERSION/

Затем, если вы хотите использовать скомпилированные пользователем двоичные файлы в /opt/$WHATEVER-$VERSION/bin , добавьте это в PATH (НЕ ПОДГОТОВЛЯЙТЕ из-за риска взлома системы).

Для статического связывания $ WHATEVER с чем-то другим

export CFLAGS="$CFLAGS -I/opt/$WHATEVER-$VERSION/include" \
   CXXFLAGS="$CXXFLAGS -I/opt/$WHATEVER-$VERSION/include" \
   LDFLAGS="-lwhatever -L/opt/$WHATEVER-$VERSION/lib"

Для общей ссылки $ WHATEVER на что-то другое

То же, что и выше, но добавьте -Wl,-rpath,/opt/$WHATEVER-$VERSION/lib в LDFLAGS

Еще одна вещь, которую нужно сделать - вместо make install использовать checkinstall для создания съемного пакета, в котором полное имя пакета включает в себя custom-$WHATEVER-$VERSION чтобы упростить управление версиями и избежать взлома пользовательских пакетов через несовместимые обновления.

|источник
0

Я только что обнаружил, что мое решение выше ломает некоторые двоичные файлы, которые требуют версию OPENSSL_1.0.1. Например, завиток. apt-file search больше не будет работать с моим решением, так как оно использует curl. Поэтому некоторым двоичным файлам нужна версия 1.0.0, а другим - версия 1.0.1.

Я считаю, что решение заключается в редактировании файла openssl.ld. Так что некоторые двоичные файлы получат версию 1.0.0, а другие - версию 1.0.1. На данный момент это за мной. Может быть, кто-то еще может решить это.

|источник

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .