rssh-discuss

debugging permission denied issue

[Terry <td...@gm...>]

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!

Re: debugging permission denied issue

[Derek M. <co...@pi...>]

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

Re: debugging permission denied issue

[Terry <td...@gm...>]

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.