Looks like a binary compatibility problem to me. Probably some version
difference between the Debian machine where the binaries were produced
and your Ubuntu machine. I suggest building from source. You can build
just the GSI-OpenSSH bundle using the instructions at:

  http://grid.ncsa.uiuc.edu/ssh/install.html

Charles Bacon wrote:
> That's very strange.  I don't know why that particular executable would
> fail when all the rest of the executables were built on the same machine
> and are also 32bit x86 binaries.  I'm copying Jim to see if he has any
> ideas, but I'm a bit stumped.  That ldd doesn't return the list of
> shared libs and execve returns "no such file" while "file" correctly
> identifies it is very strange!
> 
> 
> Charles
> 
> On Nov 26, 2008, at 4:16 AM, Akira Akira wrote:
> 
>> Sorry for this late reply. Anyway, when I try to execute ssh-keygen
>> something odd happens:
>>
>> [EMAIL PROTECTED]:/usr/local/globus-4.2.1.1/bin/ssh.d$ export
>> GLOBUS_LOCATION=/usr/local/globus-4.2.1.1
>> [EMAIL PROTECTED]:/usr/local/globus-4.2.1.1/bin/ssh.d$ ./ssh-keygen
>> -bash: ./ssh-keygen: No such file or directory
>> [EMAIL PROTECTED]:/usr/local/globus-4.2.1.1/bin/ssh.d$ file ssh-keygen
>> ssh-keygen: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
>> for GNU/Linux 2.4.1, dynamically linked (uses shared libs), not stripped
>> [EMAIL PROTECTED]:/usr/local/globus-4.2.1.1/bin/ssh.d$ strace ./ssh-keygen
>> execve("./ssh-keygen", ["./ssh-keygen"], [/* 22 vars */]) = -1 ENOENT
>> (No such file or directory)
>> dup(2)                                  = 3
>> fcntl(3, F_GETFL)                       = 0x8002 (flags
>> O_RDWR|O_LARGEFILE)
>> fstat(3, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
>> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
>> 0) = 0x7f40b408f000
>> lseek(3, 0, SEEK_CUR)                   = -1 ESPIPE (Illegal seek)
>> write(3, "strace: exec: No such file or di"..., 40strace: exec: No
>> such file or directory
>> ) = 40
>> close(3)                                = 0
>> munmap(0x7f40b408f000, 4096)            = 0
>> exit_group(1)                           = ?
>> Process 3699 detached
>> [EMAIL PROTECTED]:/usr/local/globus-4.2.1.1/bin/ssh.d$ ldd ssh-keygen
>>     not a dynamic executable
>> [EMAIL PROTECTED]:/usr/local/globus-4.2.1.1/bin/ssh.d$ ls -la
>> total 1124
>> drwxr-xr-x 2 globus globus   4096 2008-11-26 07:34 .
>> drwxr-xr-x 3 globus globus  12288 2008-10-02 22:54 ..
>> -rwxr-xr-x 1 globus globus  63514 2008-10-02 22:52 scp
>> -rwxr-xr-x 1 globus globus  97133 2008-10-02 22:52 sftp
>> lrwxrwxrwx 1 globus globus      5 2008-11-20 07:26 slogin -> ./ssh
>> -rwxr-xr-x 1 globus globus 348365 2008-10-02 22:52 ssh
>> -rwxr-xr-x 1 globus globus 126398 2008-10-02 22:52 ssh-add
>> -rwxr-xr-x 1 globus globus 101519 2008-10-02 22:52 ssh-agent
>> -rwxr-xr-x 1 globus globus 154013 2008-10-02 22:52 ssh-keygen
>> -rwxr-xr-x 1 globus globus 204638 2008-10-02 22:52 ssh-keyscan
>>
>>
>> Maybe this is happening because ssh-keygen was compiled to 80386
>> instead of x86-64? I already have all the same executables on my
>> /usr/bin. Can I just replace those executables with symbolic links?
>> Any other ideas?
>>
>> Thanks in advance.
>>
>> Regards,
>>
>>                     Akira
>>
>>
>> On Thu, Nov 20, 2008 at 11:22 PM, Charles Bacon <[EMAIL PROTECTED]>
>> wrote:
>> Oh, sorry, I didn't realize it was a binary installer.
>>
>> I just double-checked the gt4.2.1 x86_deb_4.0 installer, and the
>> gsi_openssh tarball in binary-trees/gsi_openss-4.4/gsi_openssh.tar.gz
>> does contain bin/ssh.d/ssh-keygen.
>>
>> Can you verify whether you have an executable at
>> /usr/local/globus-4.2.1.1/bin/ssh.d/ssh-keygen or not?  If you do,
>> what happens if you run it?
>>
>>
>> Charles

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to