Thanks Les. PATH correction did the trick.
On 5/20/07, Les Mikesell <lesmikesell@xxxxxxxxx> wrote:
Anne Wilson wrote:
>
>> I've tried several recommendations to enable 'rsh' for the user
>> 'root'. I know about the pitfalls and dangers or doing same, but I
>> must have this because of particular need for the software suites I am
>> running.
>> I am able to run 'rsh' just fine for all other users. It's just for
>> 'root' that I am facing problems.
>>
>> I've attempted by adding 'rsh', 'rlogin', 'rexec' in /etc/securetty
>> file, i.e. first three lines. Didn't help.
>> I've attempted by adding the 'server_options = o' & 'server_options =
>> -o' in the /etc/xinitd.d/rsh file. Didn't help.
>>
>> On running the following,
>> # rsh <myhostname> pwd
>>
>> I get:
>> Trying krb4 rsh...
>> krb_sendauth failed: You have no tickets cached
>> trying normal rsh (/usr/bin/rsh)
>> Permission denied.
>>
>> Also, if someone is aware of how to disable the feature of rsh to
>> attempt connection using Kerberos ?
>>
> I'm not a coder, so perhaps I'm misunderstanding you, but isn't the usual
> recommendation for security that you should ssh log in as user, then su to
> root?
That's assuming the thing on the other end is capable of running ssh.
It has been a while since I've had to use anything that isn't but I'm
sure such things still exist.
If you look at your $PATH you'll understand why the kerberos versions of
things run, although I've never understood why that is the default for
everyone. The permission denied part appears to be coming after the
normal rsh command runs and it is failing because you don't have a
suitable .rhosts file entry on the target machine to permit commands
from your source machine.
--
Les Mikesell
lesmikesell@xxxxxxxxx
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
