Transfer files using sudo

[Fedon Kadifeli]

We are trying to eliminate the use of passwords for *generic* users like root, oracle etc. To do this we plan to use sudo and give permission to *specific* users to switch to root, oracle etc. using "sudo -i" for example.

This solves the problem of logging in as a generic user to the system. However, from time to time there will be a need to transfer files (using scp, sftp or whatever) to or from a system using a *generic* user. For example assume you want to transfer a very large file to your PC which can only be accessed by the root user.

How do you satisfy that kind of needs in real life?

[Steven Schweda]

> How do you satisfy that kind of needs in
> real life?

Fix the contradiction in the requirements?
Correct me if I'm wrong, but you seem to want
a non-root user to be able to access a file
"which can only be accessed by the root
user."

[Fedon Kadifeli]

Yes.

Let me be more clear.

User "user1" is a system admin and can use "sudo -i" to get root shell (so he/she can do anything a root can do without knowing the actual root password). How can "user1" transfer a file which can only be accessed by root? The option of chmod/chown or cp the file to give it "user1" ownership is not acceptable, considering it is a very large file that needs to be kept secure.

[David Child_1]

Your best bet is to set up ssh keys, then you can transfer files as root (or oracle, etc.).

Note: In this example I'll use oracle (note: this is very high level);
1) create key on source system (ssh-keygen) as oracle (this will be in ~oracle/.ssh)
2) copy public key to destination system and put in oracle's ~oracle/.ssh/authorized_keys file.

Now you can scp files from source->destination as oracle without needing the password.

Note: when creating the key it will give the option of creating a pass phrase. I would recommend doing this. If you need to automate your process you can use an ssh key agent to help with the pass phrase.

David

[Fedon Kadifeli]

"ssh keys" was an option that we are considering. Any other more flexible options from "real life"?

[Steven Schweda]

SSH is pretty flexible (and real).

> [...] considering it is a very large file
> that needs to be kept secure.

It's easier to consider requirements like
this when they're known. Perhaps you should
make a list. SSH access as "root" may allow
a non-root user to do more than copy files,
too.

[Steven Schweda]

> Let me be more clear.

> [...] How can "user1" transfer a file which
> can only be accessed by root?

That's clear. It's impossible. Either
"user1" _can_ access the file, or else only
"root" can can access the file. They can't
both be true. There are various methods by
which "user1" might access a well-protected
file, but there's no way to access a file
which can't be accessed.

If you wish to give "user1" read access to a
file, this could be done using an access
control list. "man 5 acl".

[Fedon Kadifeli]

Let me be more specific about my needs. I (as a system admin) want to give the *specific* user "johnthedba" full "oracle" user priviledges without giving the password of "oracle". Actually nobody in the universe (including me) will know the password of "oracle" user.

The user "johnthedba" will do anything "oracle" can do including copying files in and out of the system. The "ssh keys" (mentioned above) is an option; however it is very slow while copying file over a Gbps LAN environment. The user "johnthedba" will copy large oracle export files to or from other systems. These files are owned by "oracle" and nobody else will have read or write access to these files, including the directory they are stored. Currently we are using ftp because it is much faster than scp or sftp.

I am considering using an ssh and netcat (nc) combination. Any other ideas?

[Tingli]

You can either sudo the user as oracle, or set all the oracle files as 770 with this user having the same group as oracle.

As for file transfer, you can use a specific command line in sudo as oracle for this user.

[Heironimus]

Something like this can work with appropriate sudo configuration and a decent ssh client:

ssh youruser@yourserver "sudo cat /something/secure" >local_copy

As for keys... they're a good solution in some situations, but letting users have ssh keys for generic accounts is almost the same as giving out the password. In both cases there is "something" that will give anybody who has it the ability to act as that user. Correctly controlling access while using ssh keys in this manner will probably be difficult.