[ale] ssh / sudo file transfer?

[Jeff Lightner]

I've done an expect setup for something else within the last 6 months.
However, it seems it wouldn't work here for the same reasons as I
currently have - the front end of the pipe would be feeding to the back
end and interfering with things.  It seems I need a way to somehow
encapsulate the tar output from the left side so that it is only called
on the right side at the exact place it is needed.

 

On the other idea someone gave about sudo -v I guess I should say I
misspoke.  My earlier findings were if I do a remote command (like the
ls I mentioned works) and then do another one it does NOT prompt for the
sudo password.   However, despite that it still has the issue doing the
tar.   Since the tar with only ssh works it appears to be the
combination of ssh and sudo that is causing the issue even though the
latter doesn't always require a password depending on how quickly one
attempts the second remote command.

 

Thanks for thinking about it though - I was just curious if anyone had
run into it before and figured out a solution already.   It seems
tantalizingly close but not quite there.  I think I'll experiment with
expect just to be sure though.

 

________________________________

From: ale-bounces at ale.org [mailto:ale-bounces at ale.org] On Behalf Of
timothy at meanor.net
Sent: Thursday, December 06, 2007 10:21 AM
To: ale at ale.org
Subject: RE: [ale] ssh / sudo file transfer?

 

I don't know how familiar you are with Expect, but I think it's your
best bet to accomplish something like this.  I've written scripts to do
things like ssh to a machine as user A, sudo su to user B, then execute
commands, though I've never tried to use it to transfer files.

HTH,
Tim

 

I'm trying to come up with a command line similar to the tar pipeline
which copies files.   The wrinkle is the user needs to first ssh to the
box as themselves then sudo su to the user name that owns the target
directory.

e.g.  Real user is ralph on server that has the real files.  This ralph
also exists on the target server.   On the target server ralph has
permissions to become oracle user by using "sudo su - oracle" and also
permission to run commands as oracle with "sudo -u oracle <command>".   

We do not have trusts established so users must input his password when
doing an ssh between the servers.   He must also input password when
executing a sudo command on the target server.   This works fine.  

It even works fine when I do something like:

ssh -tt ralph at remotehost "sudo -u oracle sh -c 'ls -l /oracle/prod'" 

Note there is a single quote and a double quote at end of above line.

In this command line it prompts for password for the ssh and then again
for the sudo.

It also works but spits an error if I do a tar pipeline without the sudo
but with the ssh:

tar c dir1 | ssh -tt ralph at remotehost "tar xvf -" 

This copies dir1 and its contents from the source server across to the
home of ralph on remote host.   As noted it works but after the ssh
password has been entered it displays:

tcgetattr: Invalid argument

and then does the transfer successfully.

However, when I attempt to add the "sudo -u" syntax to the pipeline it
spits the same error as above but never really logs in.  It appears that
the sudo is getting the tar information from left side of pipe and
trying to use that for the sudo password.   I've tried various quoting
and parenthetical notation but nothing works.

I'm wondering if anyone has successful pipeline for such file transfers
or some other solution that does not require me to enable ssh trusts for
the user or to setup special sudo commands.   What I'm looking for is
one off transfers not something the user will be doing every day so I
don't want to have to modify sudoers or rsync authorization when they
happen to need to transfer a file in a hurry.

----------------------------------
CONFIDENTIALITY NOTICE: This e-mail may contain privileged or
confidential information and is for the sole use of the intended
recipient(s). If you are not the intended recipient, any disclosure,
copying, distribution, or use of the contents of this information is
prohibited and may be unlawful. If you have received this electronic
transmission in error, please reply immediately to the sender that you
have received the message in error, and delete it. Thank you.
----------------------------------

 

-------------- next part --------------
An HTML attachment was scrubbed...