Problem with SCP for a restricted user
I have a problem using SCP on linux. I have my BIND 9 server running in chroot as a restricted user. The user has no shell and is set up in /etc/password thusly:
named:x:60000:60000::/var/
The only way I can get SCP to work is if I remove /sbin/nologin from /etc/passwd. This means that the user has a shell. Does anyone have an idea how to make this work with no shell for the user?
There is no password set up for the user, so theoretically unless you're already root you can't log in as that user. But this machine is on our DMZ and I'd like to be as secure as possible.
Maybe a shell that is very restricted?
named:x:60000:60000::/var/
The only way I can get SCP to work is if I remove /sbin/nologin from /etc/passwd. This means that the user has a shell. Does anyone have an idea how to make this work with no shell for the user?
There is no password set up for the user, so theoretically unless you're already root you can't log in as that user. But this machine is on our DMZ and I'd like to be as secure as possible.
Maybe a shell that is very restricted?
A little background on the thing would help solve this problem.
/Rob
/Rob
ASKER
I have fixed the problem, So I'm going to close the question.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Chris, I'll have to experiment with that one. But your answer was intriguing enough that I have retracted my "close question" request.
Basically, here's my dilemna guys: I am running BIND as a restricted user. That user owns all BIND configuration files. That user also has no shell and no password. But I have both servers running as SOA DNS for full failover capability (unlike secondary, which will eventually expire its cache). So if I need to make a change to one, I wrote a script that will copy the db files over to the other and run rndc to reload the remote named process. In order to copy the files back and forth the restricted user needs write access to them.
The only real vulnerability, even with a shell (but no password), would be if there were some future BIND exploit that allowed an attacker to break out into a shell. And in that case, even though the user is chrooted, I am in trouble.
So I can try Chris's suggestion. But I have another idea... I could create a new user in a unique group and chown
named-user:new-users-group
Basically, here's my dilemna guys: I am running BIND as a restricted user. That user owns all BIND configuration files. That user also has no shell and no password. But I have both servers running as SOA DNS for full failover capability (unlike secondary, which will eventually expire its cache). So if I need to make a change to one, I wrote a script that will copy the db files over to the other and run rndc to reload the remote named process. In order to copy the files back and forth the restricted user needs write access to them.
The only real vulnerability, even with a shell (but no password), would be if there were some future BIND exploit that allowed an attacker to break out into a shell. And in that case, even though the user is chrooted, I am in trouble.
So I can try Chris's suggestion. But I have another idea... I could create a new user in a unique group and chown
named-user:new-users-group
ASKER
One more thing. the obvious thing to do would be to run scp/sftp as root. In fact the script I wrote must be run as root. But I'm not allowing remote root access to these servers and have no intention to...
What I'm hoping for is a solution that isn't too klugy
What I'm hoping for is a solution that isn't too klugy
Mike, both your ideas could work in this case. As for getting a shell if there is a Bind exploit, I don't think this will be easier if the user has a valid shell in /etc/shells, since most attacks don't bother to check $SHELL, but rather just launch /bin/sh since it almost always works. If the chroot area has no /bin/sh, then you're OK.
/Rob