Re: OpenSHH installation (Operating System G06, Release G06.32.00)
- From: Keith Dick <kdick@xxxxxxx>
- Date: Mon, 25 Apr 2011 22:25:35 +0200
Keith Dick wrote:
Keith Dick wrote:
Alex wrote:
On Apr 25, 10:27 am, Keith Dick <kd...@xxxxxxx> wrote:
Alex wrote:
On Apr 22, 3:02 am, "Joachim Schmitz" <nospam.j...@xxxxxxxxxxxxxxxxxx>
wrote:
Alex wrote:
We unzipped packages in OSS (openssl, prngd and openshh) with
following commands:
-tar -zxvf /tmp/prngd-0.9.27-nsr.tar.gz
-tar -zxvf /tmp/openssl-0.9.7g-nsr.tar.gz
-tar -zxvf /tmp/openssh-3.7.1p2-nsr.tar.gz
This should answer an earlier question of mine: you're on TNS/R, S-Series
Hardware, G-Series OS
What release, what does 'gtacl -p sysinfo' say?
When executing ssh from /usr/local/bin we get some output:
Which seems to stem from _RLDVERBOSE=3, right? Although my output looks
slightly different, I have additional emtpy lines.
/usr/local/bin: ssh -V
0001:Loaded Library '/usr/local/bin/ssh',
Segment base address = 0x70000000,
Rebase amount = 0x00000000
0002:Loaded Library 'ZRLDSRL',
Segment base address = 0x765c0000,
Rebase amount = 0x00000000
0003:Loaded Library '/usr/local/lib/libcrypto.so',
Interesting, I'd have expexted this lib to get loaded and it does look that
way on TNS/E, but it does not on our TNS/R G06.32 lab machine.
Segment base address = 0x60000000,
Rebase amount = 0x00000000
0004:Loaded Library 'zutilsrl',
Segment base address = 0x76c00000,
Rebase amount = 0x00000000
0005:Loaded Library 'zosscsrl',
Segment base address = 0x76660000,
Rebase amount = 0x00000000
0006:Loaded Library 'zcresrl',
Segment base address = 0x76600000,
Rebase amount = 0x00000000
0007:Loaded Library 'zcrtlsrl',
Segment base address = 0x76c20000,
Rebase amount = 0x00000000
0008:Loaded Library 'zossksrl',
Segment base address = 0x76d40000,
Rebase amount = 0x00000000
0009:Loaded Library 'zsecsrl',
Segment base address = 0x76640000,
Rebase amount = 0x00000000
0010:Loaded Library 'zossesrl',
Segment base address = 0x76e00000,
Rebase amount = 0x00000000
0011:Loaded Library 'zinetsrl',
Segment base address = 0x76ce0000,
Rebase amount = 0x00000000
0012:Loaded Library 'zstfnsrl',
Segment base address = 0x77040000,
Rebase amount = 0x00000000
0013:Loaded Library 'zossfsrl',
Segment base address = 0x76a40000,
Rebase amount = 0x00000000
0014:Loaded Library 'zicnvsrl',
Segment base address = 0x76b40000,
Rebase amount = 0x00000000
0015:Loaded Library 'zi18nsrl',
Segment base address = 0x76a60000,
Rebase amount = 0x00000000
OpenSSH_3.7.1p2, SSH protocols 1.5/2.0, OpenSSL 0.9.7g 11 Apr 2005
When trying to generate keys we receive error:
/usr/local/bin: ssh-keygen
0001:Loaded Library '/usr/local/bin/ssh-keygen',
Segment base address = 0x70000000,
Rebase amount = 0x00000000
*** RLD ERROR ***: DLL File Format Error: File ssh is a program; a
library was expected
/bin/-sh: ssh-keygen: invalid cpu specified to tdm_execve()
Where are these libraries? Should libraries be linked somehow?
There is no need to do anything special, not even _RLD_LIB_PATH needs to get
set.
I don't understand what goes wrong on your machine, it works just as it
should on mine, S-Series, G06.32, as well as NS-Series, J06.10
What is your _RLD_LIB_PATH set to, what does PATH look like?
Bye, Jojo- Hide quoted text -
- Show quoted text -
My PATH looks like:
PATH=/bin:/bin/unsupported:/usr/bin:/usr/ucb:/usr/tandem/sqlmx/bin:.::/
usr/local
/lib
and _RLD_LIB_PATH=/usr/local/lib
The content of /usr/local/bin is:
/usr/local/bin: ls /usr/local/lib
libcrypto.a libcrypto.so libssl.a libssl.so
pkgconfig
The error shows:
/usr/local/bin: ssh-keygen
*** RLD ERROR ***: DLL File Format Error: File ssh is a program; a
library was e
xpected
I would expect libcrypto.so to have all necessary components.
Again, we are far from solution on our side.
How wild and crazy can you get with that system? If possible, one thing I would try is find the ssh program, temporarily rename it to xxx, and see how that changes things. Remember to rename it back to ssh right after that test.
Did you ever try setting _RLDVERBOSE to 8 and see what additional information it tells you when trying to run ssh-keygen? That might tell you nothing, but it might give some hint as to what is happening.
As I said before, I don't have any experience with this, so I'm just guessing. It really ought to work without all this trouble, as Jojo said, but it doesn't for you. All I can think of is try experiments and look around to see whether anything looks like it might explain what is happening.
You mentioned that you would expect that libcrypto.so has all the necessary components, but the output triggered by _RLDVERBOSE says nothing about loading libcrypto.so, so whatever it contains seems not to be used. I see Jojo said that, although _RLDVERBOSE shows that libcrypto.so gets loaded on a TNS/E, it does not get loaded on the TNS/R he uses. So what does that mean? Maybe the program is statically linked for TNS/R. That still doesn't explain why it is trying to load ssh though.- Hide quoted text -
- Show quoted text -
I renamed ssh from /usr/local/bin and another execution of ssh-keygen
requires ssh library to run.
/usr/local/bin: ssh-keygen
0001:Loaded Library '/usr/local/bin/ssh-keygen',
Segment base address = 0x70000000,
Rebase amount = 0x00000000
0002:Searching for load file 'ssh' in Public library location.
0003:Searching for load file 'ssh' in Program's location.
0004:Searching for load file 'ssh' in location '/usr/local/lib'.
0005:Searching for load file 'ssh' in location '/lib'.
0006:Searching for load file 'ssh' in location '/usr/lib'.
0007:Searching for load file 'ssh' in location '/G/SYSTEM/ZDLL'.
*** RLD ERROR ***: FileSystem Error 11: File /G/SYSTEM/ZDLL/ssh NOT
Found
/bin/-sh: ssh-keygen: tdm_execve(): failed with unexpected error
pr_errno=(4022) pr_TPCerror=(75) pr_TPCdetail=(11)
It is unclear why is even looking for it on our system? Will give it
more research now.
Well, that didn't tell us anything new, did it? I agree that it seems odd that ssh-keygen is trying to load something named ssh. I have no idea why it is doing that and seems not to do it on Jojo's system. I'm going to try to download the source and see whether I can spot any clues in a quick look at ssh-keygen's source, assuming I can find it.
Okay, I looked around a little (on a Windows PC, not using a NonStop system, so I cannot try anything). The ssh-keygen object file contains, starting about 1850 bytes into the file, the following:
ssh libcrypto.so zutilsrl zosscsrl zrldsrl zcresrl zcrtlsrl zossksrl zossfsrl zsecsrl zi18nsrl zicnvsrl zossesrl zinetsrl zstfnsrl zosshsrl
At first glance, this looks like the list of libraries it should load, and ssh is right up front. You said earlier that noft listed nothing when you asked it to show the list of libraries. Maybe this isn't a list of libraries, but if not, I don't know what it is.
Makefile.in contains this line:
ssh-keygen$(EXEEXT): $(LIBCOMPAT) libssh.a ssh-keygen.o
$(LD) -o $@ ssh-keygen.o $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS)
which strongly suggests that ssh is being named as a library in the build. I believe this file is only a sort of template for the actual make file (which I believe is created by the configure script), and I cannot see what the actual values are for LD LDFLAGS and LIBS, since they are @LD@ @LDFLAGS@ and @LIBS@ -- which I believe are replaced by configure.
So it seems that the make file, whether correctly or not, has listed ssh as a library. I don't know whether there is a way to modify the object file to remove a library reference. Maybe an easy way to try to work around it would be to create a dll named ssh which contains just a junk function, not related to anything, put it in /usr/local/lib and see how far you get. If you know how to create a dll, it should be easy to try that. If you don't know how to create a dll, I think it isn't hard, and if you can't figure it out from the docs, maybe I, or someone else here, can help you out with that.
It very well could be that just putting in a place-holder dll like that won't solve the problem, but unless there is a way to remove a library reference from an object file, I don't know what else you could try. Well, you could try rebuilding ssh from its sources, but I have a feeling that is harder.
Once more, I don't know *anything* about this -- I'm just making guesses.
An easier way to create a place-holder dll might be to select some existing, unrelated dll and make a copy of it to /usr/lib/ssh. There is some risk that a name in whatever dll you pick would clash with one of the names exported from one of the other dlls, and I don't know what the effect of that would be. If name clashes don't matter, then I suppose you could just copy libcrypto.so to ssh.
None of the place-holder tricks will work if there is some checking at load time that the dll exports a list of function names that are referenced by the main program, unless maybe for ssh that list is empty (since we are making the assumption that ssh was incorrectly included in the list of libraries).
.
- Follow-Ups:
- References:
- OpenSHH installation (Operating System G06, Release G06.32.00)
- From: Alex
- Re: OpenSHH installation (Operating System G06, Release G06.32.00)
- From: Joachim Schmitz
- Re: OpenSHH installation (Operating System G06, Release G06.32.00)
- From: Alex
- Re: OpenSHH installation (Operating System G06, Release G06.32.00)
- From: Keith Dick
- Re: OpenSHH installation (Operating System G06, Release G06.32.00)
- From: Alex
- Re: OpenSHH installation (Operating System G06, Release G06.32.00)
- From: Keith Dick
- OpenSHH installation (Operating System G06, Release G06.32.00)
- Prev by Date: Re: OpenSHH installation (Operating System G06, Release G06.32.00)
- Next by Date: A. G. Lisi's E8 model may be showing us what both our space & time really are.
- Previous by thread: Re: OpenSHH installation (Operating System G06, Release G06.32.00)
- Next by thread: Re: OpenSHH installation (Operating System G06, Release G06.32.00)
- Index(es):
Relevant Pages
|