Thread: debugging permission denied issue
Brought to you by:
xystrus
From: Terry <td...@gm...> - 2012-12-19 17:22:59
|
We just upgraded to 2.3.3 (via EPEL on RHEL 6). After the upgrade, our users get this when trying to simply scp in: /usr/bin/rssh: Permission denied lost connection The security logs show this: Dec 19 11:20:38 server01 sshd[19499]: Accepted keyboard-interactive/pam for tdtest from ::1 port 42920 ssh2 Dec 19 11:20:38 serverws01 sshd[19499]: pam_unix(sshd:session): session opened for user tdtest by (uid=0) Dec 19 11:20:38 server01 sshd[19509]: Received disconnect from ::1: 11: disconnected by user Dec 19 11:20:38 server01 sshd[19499]: pam_unix(sshd:session): session closed for user tdtest The only thing not commented out in rssh.conf is this: logfacility = LOG_USER allowscp allowsftp allowcvs allowrdist allowrsync umask = 022 The users are all part of an "sftp" group that has this in /etc/security/access: +:sftp:ALL I am not sure how to further debug this. Anyone have some ideas? Thanks! |
From: Derek M. <co...@pi...> - 2012-12-20 01:31:33
|
On Wed, Dec 19, 2012 at 11:22:51AM -0600, Terry wrote: > We just upgraded to 2.3.3 (via EPEL on RHEL 6). After the upgrade, > our users get this when trying to simply scp in: > /usr/bin/rssh: Permission denied This usually means that the program does not have execute permissions. In the case of a shell (such as rssh), however, it could also mean that the program that the shell is trying to execute does not have execute permissions. So look at the file permissions on rssh and on the scp binary, and make sure they have appropriate permissions for the users/groups who will be running them. At any rate, this really isn't an rssh problem per se. > The users are all part of an "sftp" group that has this in /etc/security/access: > +:sftp:ALL > > I am not sure how to further debug this. Anyone have some ideas? It could also be that this is somehow failing. You could debug by temporarily changing a user's shell to bash and running id after they log in. Also look at the system logs (generally /var/log/messages) or wherever you have rssh configured to log. The USER log facility is (by default) configured to log to a different log file than the AUTH facility. There may be more info there. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D |
From: Terry <td...@gm...> - 2012-12-20 01:43:03
|
On Wed, Dec 19, 2012 at 7:31 PM, Derek Martin <co...@pi...> wrote: > On Wed, Dec 19, 2012 at 11:22:51AM -0600, Terry wrote: >> We just upgraded to 2.3.3 (via EPEL on RHEL 6). After the upgrade, >> our users get this when trying to simply scp in: >> /usr/bin/rssh: Permission denied > > This usually means that the program does not have execute permissions. > In the case of a shell (such as rssh), however, it could also mean > that the program that the shell is trying to execute does not have > execute permissions. So look at the file permissions on rssh and on > the scp binary, and make sure they have appropriate permissions for > the users/groups who will be running them. At any rate, this really > isn't an rssh problem per se. > >> The users are all part of an "sftp" group that has this in /etc/security/access: >> +:sftp:ALL >> >> I am not sure how to further debug this. Anyone have some ideas? > > It could also be that this is somehow failing. You could debug by > temporarily changing a user's shell to bash and running id after they > log in. > > Also look at the system logs (generally /var/log/messages) or wherever > you have rssh configured to log. The USER log facility is (by > default) configured to log to a different log file than the AUTH > facility. There may be more info there. > > -- > Derek D. Martin > http://www.pizzashack.org/ > GPG Key ID: 0x81CFE75D > You're right. Not an rssh issue. The binary had 750 permissions on it with root:rsshusers and the users were not in this group. Apparently the upgraded package tightened these permissions. Thank you for the nudge. |