nenhuma informação de versão disponível (requerida por / usr / bin / ssh)

Question

Estou recebendo no version information available ao criar ssh .

Openssl verion:

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

Aqui está a saída de 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)

Saída de 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

Como corrigir esse erro?

Nota:

Eu compilei e instalei o openssl . Depois disso, instalei ssh a apt-get .

    

Answer 1

I compiled and installed the openssl. After that, I installed ssh through apt-get.

Estas são provavelmente duas versões diferentes do OpenSSL. Você provavelmente estará OK, já que 1.0.0 é compatível com binário 1.0.1, 1.0.2, etc (mas não será compatível com o binário 1.1.0).

Seu ssh provavelmente está usando a versão do OpenSSL em /usr/lib/x86_64-linux-gnu/ . Você deve usar LD_PRELOAD para garantir que sua versão do OpenSSL esteja sendo usada (assumindo compatibilidade binária, é claro).

Se você não quiser usar LD_PRELOAD e amigos, crie ssh de fontes. Certifique-se de especificar um rpath para garantir que o editor de links use sua versão do OpenSSL, não a versão do sistema. Ou seja, seu LDFLAGS deve incluir algo como -Wl,-rpath,<path to your openssl> . Isso é um acréscimo aos habituais -lcrypto , -lssl e -L<path to your openssl> .

Se você estiver no Mac OS X, saiba que as opções de vinculador, como -Bstatic e -rpath , são silenciosamente ignoradas. Você encontrará falhas misteriosas devido a binários incompatíveis porque o OS X fornece 0.9.8.

no version information available

Quanto a nenhuma informação de versão, não faço ideia. ssh pode usar OPENSSL_VERSION_NUMBER no tempo de compilação ou SSLeay / SSLeay_version no tempo de execução. Consulte OPENSSL_VERSION_NUMBER(3) para obter detalhes.

How to fix this error?

Talvez eu esteja interpretando mal as coisas, mas não vejo nenhum erro em nenhum lugar da postagem.

    

Answer 2

Problema: libssl.so.1.0.0 e libcrypto.so.1.0.0 nenhuma informação da versão disponível aviso / erro.

Depois de muita pesquisa, tempo e esforço, (levou semanas), aqui está o que eu finalmente acabei fazendo ...

No diretório em que você acabou extraindo o código fonte para sua versão do openssl 1.0.1h (deve funcionar para outras versões também). Eu crio um arquivo chamado openssl.ld

Neste arquivo coloque isso ...

OPENSSL_1.0.0 {
    global:
    *;
};

salve. Agora digite ...

make clean

(Só para ter certeza de que estamos começando de novo.)

Agora, para a parte realmente incompreensível ...

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

Então ...

make
make test
make install
ldconfig

E isso deve ser feito. (É tão simples. Nenhum patch é necessário.)

Eu apliquei esta solução ao Debian Wheezy nas versões de 32 e 64 bits. E fiz uma observação. A versão de 64 bits é padronizada automaticamente para os novos arquivos libssl.so.1.0.0 e libcrypto.so.1.0.0 criados no diretório /usr/local/lib . A versão de 32 bits não. É por isso que eu pensava a princípio que a versão de 32 bits do Debian Wheezy não sofreu com esse problema, mas acontece assim que você obtém a versão de 32 bits para usar as novas bibliotecas openssl no /usr/local/lib dir.

Usar o comando ldd para testar quais bibliotecas os binários estão usando foi inestimável em descobrir isso também.

    

Answer 3

Acabei de descobrir que minha solução acima quebra determinados binários que exigem uma versão OPENSSL_1.0.1. Como onda por exemplo. A pesquisa do apt-file não funcionará mais com a minha solução, pois ela usa o curl. Portanto, alguns binários querem uma versão 1.0.0 e outros querem uma versão 1.0.1.

Eu acredito que a solução está em uma edição do arquivo openssl.ld. Assim, alguns binários receberão a versão 1.0.0 e outros receberão uma versão 1.0.1. No momento, isso está além de mim. Talvez alguém possa resolver isso.

    

Answer 4

Se você deseja instalar bibliotecas personalizadas, não quebre o sistema instalando os prefixos /usr/local , /usr ou / . O Debian / Ubuntu, por exemplo, irá pegar bibliotecas customizadas em /usr/local/lib da próxima vez que ldconfig for invocado porque normalmente é listado em /etc/ld.so.conf.d/libc.conf .

Aqui está uma caixa descartável com o openssl 1.0.2e make install 'ed para --prefix=/usr/local e, em seguida, executa ldconfig (sem argumentos, o que atualiza /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

Observe como os compilados sob encomenda substituem libs do pacote openssl .

Em vez disso, a solução é para vendedor bibliotecas e binários personalizados em diretórios isolados que são independentes do padrão ld.conf e PATH.

Instale o software em /opt/$WHATEVER-$VERSION/

Então, se você quiser usar binários compilados sob encomenda em /opt/$WHATEVER-$VERSION/bin , acrescente ao PATH (NÃO PREPARE, por causa do risco de quebrar o sistema).

Para static ligando $ WHAVERVER a outra coisa

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

Para compartilhado ligando $ WHAVERVER a outra coisa

O mesmo que acima, mas adicione -Wl,-rpath,/opt/$WHATEVER-$VERSION/lib a LDFLAGS

Outra coisa a fazer é, em vez de usar make install checkinstall para criar um pacote removível onde o nome completo do pacote inclui custom-$WHATEVER-$VERSION para permitir um gerenciamento de versão mais fácil, evitando quebrar pacotes personalizados por meio de atualizações incompatíveis.