Bad line received from identity server... when remsh from HP-UX to RHEL 3

[Magnus Andersen]

Hi All,

I'm trying to setup rsh and rlogin so I can use it. It works fine now but I am receiving the following in my messeges log file on the linux server.

Aug 11 13:45:41 oradev xinetd[21449]: Bad line received from identity server at 192.168.xxx.xxx: 1023 , 514 : ERROR : UNKNOWN-ERROR

I have this working on the other server without problems. I think the
problem might be on the HP-UX side since the other server, also HP-UX, does not trigger this entry in the log file.

Any ideas on how to solve this?

Thanks,
--
Magnus Andersen
Systems Administrator / Oracle DBA
Walker & Associates, Inc.

[Mel Burslan]

is this 192.168.xxx.xxx your problem generating HPUX server's address ? If not what is it ? How are you doing the user authentication ? Are you using something like .netrc or just waiting for password prompt and maually entering the password ? And how is it done on the server which does not have any problems ?

[Magnus Andersen]

Yes the 192 address is the server I'm trying to access from. I've set up a .rhosts file in the user directory allowing certain users from certain servers to access without using passwords as that user. Both servers are working the same way. Both servers are running HP-UX 11.0.

Thanks,
Magnus

[Mel Burslan]

As you are eventually able to logon, this I am assuming is a minor annoyance. Did you check to see if you are getting this error before you get authenticated or right after your authentication completes and you see the shell prompt ?

to observe this, prior to launching rogin from hpux, pop open a new window to your redhat linux machine and run command

tail -f /var/log/messages

assuming this is where your log is located, and while watching it, from the hpux side, start your rlogin session and see the timing when this error message gets logged.

I have never seen such a thing happening, so I am just suggesting ways to get to the root of this issue.

[Magnus Andersen]

The reason I'd like to fix it is that I am going to have a script running every 5 minutes checking a process on the remote server. That is going to fill my logs up and I might actually miss something important. It looks to me like I am receiving the prompt before the message is logged in /var/log/messages and I believe it is after the authentication. I've never seen this before either...

Magnus

[TwoProc]

Magnus,

A different answer than what you're seeking - but you really should be thinking about using ssh for this instead of rsh. Just 5 cents worth of free advice.

[Magnus Andersen]

I'm not sure how to set it up using ssh. I have a script that runs every five minutes on server 1 (HP-UX), it is in turn (right now, but I am open to suggestions) remsh to execute a script on server 2 (RHEL 3). That script is verifying that my database is up or down and the answer is used on server 1 to determine if it should start/re-start a Peoplesoft process scheduler. Here is my function...

function WhatIsPrcsStatus
{
if [ `eval "remsh oradev -l oracle /usr/local/bin/Check4PSERVERtst"` -eq 1 ]
then
PRCS_DEAD=1
else
PRCS_DEAD=0
fi
}

Thanks,
Magnus

[Mel Burslan]

Magnus,

As John indicated in his message, ssh is a more secure and much better way of accomplishing this. If I am not mistaken, RHEL 3 delivers openssh at the time of system installation. Just check to see if sshd is running on this rhel server. If it is running, your job is as easy as to generate a pair of public and private keys and put the public key in RHEL box' ~oracle/.ssh/authorized_keys and put the private key in hpux server users's $HOME/.ssh/known_hosts file and you are good to go. Then you replace remsh command with ssh. That's all there is to it.

Coming back to the problem at hand, I am not sure what is triggering that message from one server and not from the other everything being equal, but on the problematic bax, you may have some outdated patches or god forbid some cutting edge patches with bugs which may be representing the user id over tcpip with some erroneous way. If you have a network admin group or have a box that you can configure as a sniffer, using something like ethereal, you can sniff the traffic at the time of session initiation and compare the alike frames to see if you are getting tagged an extroneous character or something. That's all I can think about. If you have a software support contract with hp, I'd suggest to log a call with them. This might be a known patch issue that no one here has ever encountered.

[TwoProc]

Magnus, not that hard, after you're set up - it's just a case of changing the "rsh" string in your command with "ssh". Literally, that's it.

However settting up ssh can get just a little involved, but b/c of what it gets you in security it is certainly one of those cases where you'll be extrememly happy you spent the 1/2 day or so learning about it and getting it set up. I know I was after I got it up.

To make the process a bit easier, I *know* that there is one of our more senior forum members who has something of a cookbook that gets up and running in a short amount of time. I just can't remember who it is offhand. If you search here in the forms for "ssh setup" or "ssh startup" you'll see it mentioned. I've seen it mentioned often, and having viewed it, I remember it being pretty good.

I'm hoping that someone who knows of the ssh "cookbook" of which I'm thinking of posts a response.

[Magnus Andersen]

I'll try and use ssh instead. If you can't fix it work around it..;)

When I change the remsh to ssh I get prompted for a password. Is there a way I can avoid that or supply it?

Thanks,
Magnus

[Magnus Andersen]

John,

I'll try and search for the cookbook. I have ssh up and running, I've just never executed command through it. I'm using it instead of telnet.

Thanks,
Magnus

[Mel Burslan]

Magnus,

Ssh first tries to authenticate using public/private key pairs. If it fails, it falls back to password authentication and does not care about .rhosts. To prevent password asking, you need to generate a pair of keys and place then as I tried to explain in my post above.

on your hpux servers, I think under /opt/ssh/bin, there should be a file called ssh-keygen for the purpose of generating these keys. Man pages should give you the instructions on how to use the keygen functionality.

[Magnus Andersen]

Thanks Mel and John.

I'm going to work on this tomorrow and get it working. It is just a matter of getting the keys correct if I understand this.

Magnus

[TwoProc · Accepted solution]

OK,

Here goes.

Given:
Server1 - commands will run from
Server2 - command will issued to
ssh is installed on both servers
sshd is running on server2


login to server1

ssh-keygen -t rsa (you can also use "dsa" instead for a longer key).

(accept all the defaults - put no password).

You'll notice a couple of new files:
id_rsa and id_rsa.pub
or
id_dsa and id_dsa.pub

id_xsa is your local secret key, KEEP IT PRIVATE.
id_xsa.pub is your public key, you'll need to copy this to the server that is going to let you in (directions below).

cd .ssh

chmod og-rwx . *

login to server2

mkdir .ssh
chmod 700 .

now (however you want to do it) copy the id_rsa.pub (id_dsa.pub if you chose dsa) file from server1 to this directory and name it "authorized_keys".

Go back to server 1:
"ssh server2"
It should give a warning about this being a new server, just be agreeable and let it do its thing.

You should be at the command prompt on server2 right now.

Appending more keys to the "known_hosts" file and more keys to "authorized_keys" file lets more servers onto this account just as "server1".

Always generate a unique key per user account and per server (don't reuse private keys).

[Magnus Andersen]

John,

I followed your last post and it worked without any problems. Thanks a bunch. One question though, in the next to last paragraph you mention a known_hosts file that is not mentioned anywhere else. Is this file needed? It seems to work great without it...

Thanks again,
Magnus

[Mel Burslan]

Magnus,

known_hosts file resides on the server initiating the ssh session. The server which fields the ssh call, compares the key stored for that particular calling server in its authorized_keys file. think of known_hosts file as a big keychain containing keys to many servers instead of them being scattered.

[Magnus Andersen]

Thanks again John and Mel.

Magnus

[Magnus Andersen]

Closing thread since I have everything working now.

Magnus