Openssh on Solaris 10 AMD64 - SSH

This is a discussion on Openssh on Solaris 10 AMD64 - SSH ; Hello, I have been having a heck of a time trying to get openssh-4.xp1 to compile on a AMD64 Solaris 10 system. All the attempts end with the following error. gcc -o ssh ssh.o readconf.o clientloop.o sshtty.o sshconnect.o sshconnect1.o sshconnect2.o ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: Openssh on Solaris 10 AMD64

  1. Openssh on Solaris 10 AMD64

    Hello,

    I have been having a heck of a time trying to get openssh-4.xp1 to
    compile on a AMD64 Solaris 10 system. All the attempts end with the
    following error.

    gcc -o ssh ssh.o readconf.o clientloop.o sshtty.o sshconnect.o
    sshconnect1.o sshconnect2.o -L. -Lopenbsd-compat/ -lssh
    -lopenbsd-compat
    -lresolv -lcrypto -lrt -lz -lsocket -lnsl
    Undefined first referenced
    symbol in file
    EVP_aes_192_cbc ./libssh.a(cipher.o)
    EVP_aes_256_cbc ./libssh.a(cipher.o)
    ld: fatal: Symbol referencing errors. No output written to ssh
    collect2: ld returned 1 exit status
    make: *** [ssh] Error 1

    I have gone through the email archives and tried the various
    suggestions
    made but none worked.

    I used the patches listed for acconfig.h, cipher.c and configure.ac. I
    installed the SUNWcry, SUNWcryr packages as well. I've tried different
    versions of openssl(0.9.7e, 0.9.7i 0.9.8a) as well. Still the compile
    ends with the above error.

    I have tried using the vanilla gcc which comes with Solaris 10 and have
    installed gcc.3.4.4 and still the same results.

    ../configure --enable-threads --prefix=/usr/local
    [--with-ssl-dir=/usr/local/ssl]
    make and gmake

    Any suggestions to what I should try next?

    Thanks.


    Carlo


  2. Re: Openssh on Solaris 10 AMD64

    In article <1132326681.585203.327480@g49g2000cwa.googlegroups. com>
    da.carlo@gmail.com writes:
    >
    >I have been having a heck of a time trying to get openssh-4.xp1 to
    >compile on a AMD64 Solaris 10 system. All the attempts end with the
    >following error.
    >
    >gcc -o ssh ssh.o readconf.o clientloop.o sshtty.o sshconnect.o
    >sshconnect1.o sshconnect2.o -L. -Lopenbsd-compat/ -lssh
    >-lopenbsd-compat
    >-lresolv -lcrypto -lrt -lz -lsocket -lnsl
    >Undefined first referenced
    > symbol in file
    >EVP_aes_192_cbc ./libssh.a(cipher.o)
    >EVP_aes_256_cbc ./libssh.a(cipher.o)
    >ld: fatal: Symbol referencing errors. No output written to ssh
    >collect2: ld returned 1 exit status
    >make: *** [ssh] Error 1
    >
    >I have gone through the email archives and tried the various
    >suggestions
    >made but none worked.
    >
    >I used the patches listed for acconfig.h, cipher.c and configure.ac. I
    >installed the SUNWcry, SUNWcryr packages as well. I've tried different
    >versions of openssl(0.9.7e, 0.9.7i 0.9.8a) as well. Still the compile
    >ends with the above error.


    You clearly have a problem with the OpenSSL version - those symbols
    aren't in old (very old) versions of OpenSSL. Your "trying" with current
    versions was not successful, i.e. the OpenSSH build didn't actually use
    the new version(s).

    I don't know what version of OpenSSL Solaris 10 ships with (if any), but
    either way you probably don't want to *replace* it - by default OpenSSL
    will install somewhere under /usr/local, and you'll need to point the
    OpenSSH build there, by using the --with-ssl-dir argument to configure.

    >I have tried using the vanilla gcc which comes with Solaris 10 and have
    >installed gcc.3.4.4 and still the same results.
    >
    >./configure --enable-threads --prefix=/usr/local
    >[--with-ssl-dir=/usr/local/ssl]
    >make and gmake


    Gcc version is certainly not relevant for the above - you need the
    --with-ssl-dir, and you need to make sure that configure actually finds
    the OpenSSL include files and libraries there (the output should say).
    If that had happened, you would have had a corresponding -L argument
    on the gcc command line above - but you didn't. You may also need to
    'make distclean' before re-running configure, or start with a freshly
    unpacked tarball.

    --Per Hedeland
    per@hedeland.org

  3. Re: Openssh on Solaris 10 AMD64

    On 2005-11-19, Per Hedeland wrote:
    > In article <1132326681.585203.327480@g49g2000cwa.googlegroups. com>
    > da.carlo@gmail.com writes:

    [...]
    >>Undefined first referenced
    >> symbol in file
    >>EVP_aes_192_cbc ./libssh.a(cipher.o)
    >>EVP_aes_256_cbc ./libssh.a(cipher.o)

    [...]
    >>I used the patches listed for acconfig.h, cipher.c and configure.ac. I
    >>installed the SUNWcry, SUNWcryr packages as well. I've tried different
    >>versions of openssl(0.9.7e, 0.9.7i 0.9.8a) as well. Still the compile
    >>ends with the above error.

    >
    > You clearly have a problem with the OpenSSL version - those symbols
    > aren't in old (very old) versions of OpenSSL. Your "trying" with current
    > versions was not successful, i.e. the OpenSSH build didn't actually use
    > the new version(s).


    For the record: the default libcrypto that ships with Solaris 10 does
    not have the 192 or 256 bit AES functions. Note that there is no
    linker error for the 128 bit AES funcrions.

    The Solaris Data Encryption Supplement (SUNWcry and SUNWcryr) packages
    are supposed to provide them. The OP has installed them, though, so
    I'm not sure what's going on (I made some suggestions over on
    the secureshell list where this query was also posted, but my reply does
    not seem to have made it past the moderator yet.)

    And I thought we'd finally outgrown those wacky crypto export laws...

    --
    Darren Tucker (dtucker at zip.com.au)
    GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
    usually comes from bad judgement.

  4. Re: Openssh on Solaris 10 AMD64


    "Darren Tucker" wrote in message
    news:437fc3c6$0$30790$5a62ac22@per-qv1-newsreader-01.iinet.net.au...
    > On 2005-11-19, Per Hedeland wrote:
    >> In article <1132326681.585203.327480@g49g2000cwa.googlegroups. com>
    >> da.carlo@gmail.com writes:

    > [...]
    >>>Undefined first referenced
    >>> symbol in file
    >>>EVP_aes_192_cbc ./libssh.a(cipher.o)
    >>>EVP_aes_256_cbc ./libssh.a(cipher.o)

    > [...]
    >>>I used the patches listed for acconfig.h, cipher.c and configure.ac. I
    >>>installed the SUNWcry, SUNWcryr packages as well. I've tried different
    >>>versions of openssl(0.9.7e, 0.9.7i 0.9.8a) as well. Still the compile
    >>>ends with the above error.

    >>
    >> You clearly have a problem with the OpenSSL version - those symbols
    >> aren't in old (very old) versions of OpenSSL. Your "trying" with current
    >> versions was not successful, i.e. the OpenSSH build didn't actually use
    >> the new version(s).

    >
    > For the record: the default libcrypto that ships with Solaris 10 does
    > not have the 192 or 256 bit AES functions. Note that there is no
    > linker error for the 128 bit AES funcrions.
    >
    > The Solaris Data Encryption Supplement (SUNWcry and SUNWcryr) packages
    > are supposed to provide them. The OP has installed them, though, so
    > I'm not sure what's going on (I made some suggestions over on
    > the secureshell list where this query was also posted, but my reply does
    > not seem to have made it past the moderator yet.)
    >
    > And I thought we'd finally outgrown those wacky crypto export laws...


    No, they're still quite active. They were found unconstitutional when
    handled by the Customs department, so they got transferred over to Commerce
    and remain capriciously enforced. It seems vital to US federal policy to
    avoid robust end-to-end encryption without the private keys stored in a
    central repository with their own unmonitored access to it. The problem has
    been in place for many years now.



  5. Re: Openssh on Solaris 10 AMD64

    Darren Tucker wrote:
    > The Solaris Data Encryption Supplement (SUNWcry and SUNWcryr) packages
    > are supposed to provide them. The OP has installed them, though, so
    > I'm not sure what's going on (I made some suggestions over on
    > the secureshell list where this query was also posted, but my reply does
    > not seem to have made it past the moderator yet.)


    > And I thought we'd finally outgrown those wacky crypto export laws...


    From my understanding it's more of an 'import' problem than 'export'
    now...

    --
    Darren Dunham ddunham@taos.com
    Senior Technical Consultant TAOS http://www.taos.com/
    Got some Dr Pepper? San Francisco, CA bay area
    < This line left intentionally blank to confuse you. >

+ Reply to Thread