When logged in to a machine via copSSH (1.3.6) and attempting to access a network resource, I get (after a 20 second delay):
-bash-3.00$ ls //ntdesk/spool
ls: //ntdesk/spool: Permission denied
Yet when running the Bash shell directly on that machine as the same user, I get:
bash-3.00$ ls //ntdesk/spool
RECYCLER
System Volume Information
According to this (ran locally):
bash-3.00$ ls -al //ntdesk
total 0
dr-xr-xr-x 1 Tom Metro mkpasswd 0 Dec 10 13:34 .
dr-xr-xr-x 1 Tom Metro mkpasswd 0 Dec 10 13:34 ..
drwxr-xr-x 1 Tom Metro mkpasswd 0 Dec 5 13:17 spool
I should have access to it.
Running that remotely produces:
-bash-3.00$ ls -al //ntdesk
ls: reading directory //ntdesk: Bad file descriptor
total 0
dr-xr-xr-x 1 Tom Metro None 0 Dec 10 13:38 .
dr-xr-xr-x 1 Tom Metro None 0 Dec 10 13:38 ..
I tried touching a file, both remotely (test) and locally (test2), to see if there were any differences in the user or group ownership, but they look the same:
-rw-r--r-- 1 Tom Metro mkpasswd 0 Dec 10 13:29 test
-rw-r--r-- 1 Tom Metro mkpasswd 0 Dec 10 13:29 test2
However the same directory listing when viewed remotely appears as:
-rw-r--r-- 1 Tom Metro None 0 Dec 10 13:29 test
-rw-r--r-- 1 Tom Metro None 0 Dec 10 13:29 test2
So it appears group IDs are being mapped to names differently in the two scenarios. And a group name of "mkpasswd" seems suspicious (there is no group of that name in /etc/group).
My /etc/passwd entry:
Tom Metro::1003:513:Tom Metro,U-STARBUG\Tom Metro,:/home/Tom Metro:/bin/bash
Seems to say I should be a member of the group None:
None:S-1-5-21-1078081533-484763869-1957994488-513:513:
and them I'm explicitly listed as a member of Users:
Users:S-1-5-32-545:545:Tom Metro,ASPNET,SvcCOPSSH,sshd
Maybe the space in the user name is fouling something up? (I tweaked the activate-user.sh script to permit spaces (I can send you the patch), as was discussed in another thread. It ran without errors.)
-Tom
Handling user names with spaces is a known bug in activation scripts and will be addressed with the next release.
Thanks.
Handling user names with spaces is a known bug in activation scripts...
But my point was that I already modified (I believe correctly) activate-user.sh to handle names with spaces. It may still be a problem with spaces in user names, but it would suggest the problem lies elsewhere in the code.
On the other hand, the differences observed between local and remote shell executions seems to suggest there is something more significant going on. Some aspects work correctly for local shell execution (such as the ability to access network shares), and other aspects don't (such as showing the correct group ID). If it was simply a matter of setup scripts not generating the config files correctly, I'd expect it to be consistently broken in both cases.
I think I'll try and reproduce the problem using a different account with out spaces and see what happens.
-Tom
Hmm, The problem might be related to restrictions of user rights of the service account. As a security measure, copssh setup removes following rights from the service account:
- Log on as a batch job
- Log on locally
- Log on through terminal services
- Access to this computer from the network
I don't see a direct connection here, but who knows ??
Hmm, The problem might be related to restrictions of user rights of the service account.
But doesn't copSSH do something to emulate the POSIX SetUID behavior so that the remotely logged-in user takes on their normal rights?
My guess is that there is something buggy in copSSH in that area, or more likely, unexpected behavior from the Microsoft APIs. Perhaps some of those restrictions applied to the service account aren't being cleared when the permission context switches.
If you can think of an experiment for me to try that might shed more light on the problem, let me know.
-Tom
I see this as months ago, but hey, maybe someone will see it and want an answer.
I haven't dug into how the server is authenticating/identifying itself to a network computer (accessing a share), but I do know on the target computer of the share you are trying to access, any user of copssh shows up as ANONYMOUS.
Therefore, at the very least, you can fix the share access issue for your users in 1 of 2 ways (use whichever you prefer):
1) Go to the permissions of the directory and/or files you want to allow access to on the network share, and allow ANONYMOUS the permissions you wish them to have.
2) Open up the group policy editor (Start, Run, gpedit.msc), navigate on the left to: Local Computer Policy / Computer Configuration / Windows Settings / Security Settings / Local Policies / Security Options. In the right hand pane after selecting Security Options, you can do either of:
A) Enable "Network access: Let Everyone permissions apply to anonymous users", or
B) Add any appropriate shares to "Network access: Shares that can be accessed anonymously"
Note that if you choose to go with option 2A, your shares you want the users to have access to will need to have Everyone permissions set appropriately. Also, you will either need to reboot, or run gpupdate in cmd shell, to refresh the group policy settings.
Not the best solution, as you can't control access on a username basis for the ssh users, but on short sleep it'll work (especially if it's just some dirs/files you want everyone to have access to anyway).