Tell me more ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.
up vote 2 down vote favorite

The following line shows the principle of a construct which I can use under Red hat 5.5:

$ echo "foo" | ssh myhost "echo \"cat <&1\" | su --login"
foo

Actually it was never clear to me why cat can read from FD #1, but it works.

Now with Red Hat 6.3 that doesn't work anymore:

$ echo "foo" | ssh myhost "echo \"cat <&1\" | su --login"
cat: -: Bad file descriptor

First question: Why does this not work anymore? Second question: Does anybody has an idea for a solution that works under Red Hat 6.3?

All ideas are appreciated.

Armin

share|improve this question

1 Answer

up vote 2 down vote

Wait, so basically you want to ssh to myhost, then immediately su to root without a password prompt, with the side effect of putting the root password in ps output for everyone on the local and possibly remote machines to see?

Yeah, umm, don't do that.

There are three ways to do this that both work everywhere and eliminate your root password disclosure (in the order I'd prefer them):

  1. Just ssh to root@myhost. Use public key authentication to avoid the password prompt. Preferably, keep your private key encrypted (but use SSH Agent and/or connection multiplexing to reduce password prompts). You can configure ssh to allow root logins with PermitRootLogin yes or only public-key ones with PermitRootLogin without-password.
  2. SSH as you currently are, but use sudo -i instead of su --login. Configure sudo (via visudo) to allow your non-root user to execute all commands as root (possibly even without a password, but then your non-root user is root-equivalent from a security standpoint)
  3. Change your PAM config to make su not prompt for a password from your non-user. Your user is once again root-equivalent from a security standpoint.
share|improve this answer
Well, actually the thing is a bit more complicated, the security is no issue. Instead of "su --login" we have – Armin Oct 5 '12 at 5:55
Well, actually the thing is a bit more complicated, the security is no issue. Instead of "su --login" we have a script_1 that does "exec sudo script2". The script_2 then does "exec chroot newRootDir su --login myUserName". But my point was anyway the issue with the redirection. A. – Armin Oct 5 '12 at 6:01
@Armin sudo has a no password option to avoid the password prompt, and su normally doesn't prompt for the password if you're root (or, alternatively, use sudo again). Other than that, I suggest asking a new question covering what you actually want answered… Please describe what you're trying to do—are you trying to execute a list of commands in the chroot (in which case, what's wrong with the shell's -c option? And why are you trying to read from stdout, instead of stdin?) If you open a new question detailing what you're trying to do, I think we'll be able to help you much more... – derobert Oct 5 '12 at 14:56
The problem was about IO redirection in the context of ssh, sudo and su, my specific use case didn't work with Red Hat 6.3 anymore. Reading from stdout (file descriptor 1) was the only way it worked under Red Hat 5.5. Now we have solved the issue, we want to transfer files from host's chroot environment to another host's chroot environment. There is not enough space here to explain more and present the working statement, but as I said the issue is solved anyway. – Armin Oct 8 '12 at 8:50

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.