permission denied (new to SFU) (Full Version)

All Forums >> [SFU / Interix / SUA Technology] >> SFU / Interix - Getting Started



Message

cgande1x -> permission denied (new to SFU) (Feb. 22, '06, 6:38:39 PM)

I'm sure others have posted similar questions but I haven't been able to find out exactly what is causing this. When I ssh into any of my servers I can't do any commands even ls and cd tell me 'permission denied'. I can cd / though and then I am able to navigate until I enter back into my home directory, then all commands (other than cd /) are denied. I have a DMZ server with SFU previously set up by someone else and I am in the process of creating another DMZ server with SFU. I am very new to SFU and thought I had everything figured out. I installed SFU as Administrator on the new DMZ and could ssh all I wanted without problems, but as soon as I log onto my domain account and try to ssh out of the new DMZ I get this permission denied problem. Any ideas on where I should start to correct this issue. As a side note, I don;t think SFU is set up correctly on the original DMZ server either, because when immediately closes any ssh connections. ssh -v displayed a successful logon followed by an immediate close of the session.

Thanks for any help,
Chris



Rodney -> RE: permission denied (new to SFU) (Feb. 23, '06, 1:15:51 AM)

The first part that you describe (cd'ing around) at first makes me think that the openssh
package has not been installed and/or the daemon (sshd) has not been started correctly.
I expect the latter. Check in the process list that ssd is running as
the local administrator -- it cannot, repeat, cannot be any other user.
"ps -e -Xunix | grep sshd"

That's my initial thought anyway. I'm away the rest of today (so a delay for any followup from me).



cgande1x -> RE: permission denied (new to SFU) (Feb. 24, '06, 12:35:40 PM)

I ran the command you posted on both the server that i CAN ssh into and the server i CANNOT ssh into (they are on the same network).

Successfull login system:
bash-3.00$ ps -e -Xunix | grep sshd
1281 - 0:00.07 sshd

System that denies connections:
bash-3.00$ ps -e -Xunix | grep sshd
1217 - 0:00.05 sshd


I did find some information about some errors caused by setting a system to AutoNeg that prevent Interix from initializing correctly and yields an event in the applications log with even ID: 1024 and the system I cannot ssh to has that event logged in the event logs. I'm trying to do as much to help the system without rebooting because this system has several people logged in around the clock and needs quite a bit of notice before bringing it offline.

Thanks for the response, can you explain to me what those grep results translate into?



markfunk -> RE: permission denied (new to SFU) (Feb. 24, '06, 11:04:02 PM)

The purpose of the "ps" was to see that sshd is really running
and to observe under which credentials.
I think Rodney really wanted to see the output from
"ps -enf | grep ssh"

He wants to see if sshd UID is 197108.



Rodney -> RE: permission denied (new to SFU) (Feb. 25, '06, 12:59:41 AM)

Mark is correct. I wanted to see which user the daemon is running as.



cgande1x -> RE: permission denied (new to SFU) (Feb. 27, '06, 3:23:38 PM)

I ran the command on both systems, this is what it returned:

bash-3.00$ ps -enf | grep ssh
1050262 1253 1953 12:17:25 n01 0:00.05 grep ssh
197108 1281 1 Feb 22 - 0:00.07 /usr/local/sbin/sshd

bash-3.00$ ps -enf | grep ssh
1050262 615 741 12:20:33 n00 0:00.00 grep ssh
197108 1281 1 Feb 22 - 0:00.07 /usr/local/sbin/sshd



cgande1x -> RE: permission denied (new to SFU) (Mar. 1, '06, 12:48:45 PM)

I had a little more time to spend looking around the servers and I found a few more interesting things. Whenever a home directory, or any new file/dir is created, it creates it with permissions 700. For example, my home directory is /users/cgande1x which was created automatically on the mounted Z: drive from the central storage server that also has SFU. When I SSH into the server I am working on, it takes me to my home dir which I have no permission to be in. If I su to the local Administrator account I can chmod 755 /users/cgande1x, then I can log back in as myself and have access to simple commands in my home directory.

My 1st question is: Why are all new files/directories being created as 750? Under the SFU Admin settings the permissions are set to create files as 755.

My 2nd question is: Why does it treat me as 'other' when I log in to a box via SSH? If I log in locally to one of the SFU servers I can do any of the commands and read/write/execute all I want because permissions are rwxr-x---, but if I SSH into the same box I cannot do anything, and that is because it thinks I am an 'other'. When I chmod the directory to 755, now the permissions are rwx-r-xr-x, it lets me read and execute.

So I guess the underlieing question in all of this is, why am I treated as an 'other' when I SSH into an SFU server?

Thanks all for your help,
Chris



Rodney -> RE: permission denied (new to SFU) (Mar. 2, '06, 12:11:11 AM)

> My 1st question is: Why are all new files/directories being created as 750? Under the SFU Admin settings the permissions are set to create files as 755.

The Win32 system is doing this work. It is setting the directory to a "Win32 state".
It's doing this with a deliberate action (i.e. specific API calls).

> My 2nd question is: Why does it treat me as 'other' when I log in to a box via SSH?

Perhaps you are not logging in as the same person -- need to check this.
When you login (both ways) check what the "id -D" command o/p's.



cgande1x -> RE: permission denied (new to SFU) (Mar. 3, '06, 12:12:27 PM)

Thanks for walking me through this Rodney. Here are the results:

logged on locally:
bash-3.00$ id -D
uid=1050262(IPLOR+cgande1x) gid=1049089(IPLOR+Domain Users) groups=1049089(IPLOR
+Domain Users), 65792(+Everyone), 131627(BUILTIN+Remote Desktop Users), 131617(B
UILTIN+Users), 131616(BUILTIN+Administrators), 66830(NT AUTHORITY+REMOTE INTERAC
TIVE LOGON), 66820(NT AUTHORITY+INTERACTIVE), 66827(NT AUTHORITY+Authenticated U
sers), 66831(NT AUTHORITY+This Organization), 4095(CurrentSession), 66048(+LOCAL
), 1049088(IPLOR+Domain Admins), 1049710(IPLOR+PasswordPropDeny)

logged on via SSH:
$ id -D
uid=1050262(IPLOR+cgande1x) gid=1049089(IPLOR+Domain Users) groups=1049089(IPLOR
+Domain Users), 65792(+Everyone), 131627(BUILTIN+Remote Desktop Users), 131617(B
UILTIN+Users), 1049088(IPLOR+Domain Admins), 131616(BUILTIN+Administrators), 409
5(CurrentSession), 66048(+LOCAL), 66820(NT AUTHORITY+INTERACTIVE), 66827(NT AUTH
ORITY+Authenticated Users)



Rodney -> RE: permission denied (new to SFU) (Mar. 3, '06, 2:27:27 PM)

mmm, well the key parts of the identity (UID, GID and most groups) are the same.
And that's what is used for checking permissions of the user versus file perms.

So your questions is "why does it treat the user as other?"
Nothing obvious with the o/p of id.
You write that the file perms are 0750 by default. What's the rest of
the information? Can you, for the directory in question, do:
"ls -ld dir" and "cacls dir"

I expect that since the directory is getting create by Win32 there might be
the wrong owner/group info or some extra deny ACE in the ACL.
When a chmod is done the entier ACl is redone.
So a "chmod 750" might fix things too.



cgande1x -> RE: permission denied (new to SFU) (Mar. 3, '06, 6:40:42 PM)

Ok, here is what I got from using the commands you gave while logged on locally:

bash-3.00$ ls -ld /dev/fs/Z
drwxr-xr-x 1 cgande1x Domain Users 0 Mar 1 17:00 /dev/fs/Z

bash-3.00$ touch this
bash-3.00$ cacls this
Z:\this IPLOR\cgande1x:(special access:)
STANDARD_RIGHTS_ALL
DELETE
READ_CONTROL
WRITE_DAC
WRITE_OWNER
SYNCHRONIZE
STANDARD_RIGHTS_REQUIRED
FILE_GENERIC_READ
FILE_GENERIC_WRITE
FILE_READ_DATA
FILE_WRITE_DATA
FILE_APPEND_DATA
FILE_READ_EA
FILE_WRITE_EA
FILE_DELETE_CHILD
FILE_READ_ATTRIBUTES
FILE_WRITE_ATTRIBUTES

IPLOR\Domain Users:(special access:)
READ_CONTROL
SYNCHRONIZE
FILE_GENERIC_READ
FILE_GENERIC_WRITE
FILE_READ_DATA
FILE_WRITE_DATA
FILE_APPEND_DATA
FILE_READ_EA
FILE_WRITE_EA
FILE_DELETE_CHILD
FILE_READ_ATTRIBUTES
FILE_WRITE_ATTRIBUTES

Everyone:(special access:)
READ_CONTROL
SYNCHRONIZE
FILE_GENERIC_READ
FILE_GENERIC_WRITE
FILE_READ_DATA
FILE_WRITE_DATA
FILE_APPEND_DATA
FILE_READ_EA
FILE_WRITE_EA
FILE_DELETE_CHILD
FILE_READ_ATTRIBUTES
FILE_WRITE_ATTRIBUTES

IPLOR\cgande1x:F

when I log on via ssh and try to run both commands I get 'Permission denied'.

If I do a chmod 755 on my home directory as root, then the problem goes away because obviosly now anyone has access to the directory, but not everyone will have root access to chmod their own home directories. If I run chmod 750 on my home directory, then I get permission denied wranings when I try to run commands through ssh again.

Also, when I try to ssh into the server I hav to give it the IP address. For example, I have 2 servers with SFU: Wingfoot and Wingfoot2. If I run ping wingfoot2 from wingfoot, it replies and successfully pings it, but if I run ssh wingfoot2 from wingfoot, it tells me it can't find the server, then if I ssh the IP address of wingfoot2, it will connect just fine.



Rodney -> RE: permission denied (new to SFU) (Mar. 3, '06, 11:17:54 PM)

quote:

Also, when I try to ssh into the server I hav to give it the IP address. For example, I have 2 servers with SFU: Wingfoot and Wingfoot2. If I run ping wingfoot2 from wingfoot, it replies and successfully pings it, but if I run ssh wingfoot2 from wingfoot, it tells me it can't find the server, then if I ssh the IP address of wingfoot2, it will connect just fine.


This shouldn't have any affect on the file/directory permission thing. This will be a DNS thing.
So I don't think that these two things are related. So I'll just leave this alone for now.

To the primary problem.
I missed seeing a few posts back that this is a letter drive. I think this is the problem.
Letter drives are associated with the logon session that creates them. Back in the NT4 and
earlier days the security of letter drives sucked. Because they were mounted using the
saved password of the logon user, it meant that all activity through through mounted
drive was done as that user that mounted it -- even if another user had access. Starting
with W2K3 this hole got plugged by the security of the local system associating the
drive letter mount with the logon session. This means, regardless of what the ACL shows,
access may be denied by the locally by the local system to the mounted filesystem.

If, as the ssh'd user, you cd to "/net/SERVER/sharename/users/cgande1x"
you'll likely get access. This is because the actual credentials of the process (from the
processes token) will be used to authenticate the user for the access. It doesn't go through
a logon session. Give this a try.



cgande1x -> RE: permission denied (new to SFU) (Mar. 6, '06, 12:53:28 PM)

I will give this a try in a few minutes but I would like to explain a little bit about our set up before I do so. The goal for the group is to have everyone's home directories on a shared drive, this drive is established as drive Z: on Wingfoot, and on our domain controller under user profiles the home directory is identified as: /net/Wingfoot/users/username (this path is on the shared Z drive). When I SSH to Wingfoot2 and do a 'pwd' it tells me /net/Wingfoot/users/cgande1x. When I log on locally and run pwd it shows /dev/fs/Z. If I run ls -l on either one it displays the exact same directory, because /net/Wingfoot/users is located on the Z drive.

Is there a better way to set this up? It sounds like this is what is causing the issues for us but I don't know how else to set up everyone's home directories on a shared drive.

Ok, so with permissions manually changed to 750 on my home directory, this is what happens when I log in via SSH using the same login and password:

$ pwd
/net/wingfoot/users/cgande1x
$ ls
ls: .: Permission denied
$ mkdir test3
mkdir: test3: Permission denied

Now, here are the same commands when I log on locally to the system:

bash-3.00$ pwd
/dev/fs/Z
bash-3.00$ ls
PUTTY.RND WINDOWS test test2 this
bash-3.00$ mkdir test3
bash-3.00$ ls
PUTTY.RND WINDOWS test test2 test3 this
bash-3.00$

I can also cd to the proper home directory when logged on locally:

bash-3.00$ cd /net/Wingfoot/users/cgande1x
bash-3.00$ pwd
/net/Wingfoot/users/cgande1x
bash-3.00$ ls
PUTTY.RND WINDOWS test test2 test3 this
bash-3.00$ rmdir test3
bash-3.00$ ls
PUTTY.RND WINDOWS test test2 this



Rodney -> RE: permission denied (new to SFU) (Mar. 6, '06, 1:04:25 PM)

mmmm, that's wierd (at least not what I would expect).

We know that the daemon is running as the correct user (197108).
So the user with the right authority is creating the token.
The user is the right user (confirmed with id).
But access is being denied -- this indicates a security token problem.

When your user is logging in is a password being provided or is it being done with a key exchange?



cgande1x -> RE: permission denied (new to SFU) (Mar. 6, '06, 1:07:21 PM)

All users manually type their passwords no matter how/where they log in



cgande1x -> RE: permission denied (new to SFU) (Mar. 6, '06, 5:20:37 PM)

Just out of curiosity I tried to su cgande1x (after logging on as cgande1x) and this fixed the problems. I logged on via SSH as cgande1x and tried to do a command like ls and got permission denied; su cgande1x and then I was able to do any commands, even mkdir this time. Here is my session:

login as: cgande1x
cgande1x@wingfoot's password:
Welcome to the Interix UNIX utilities.

DISPLAY=localhost:0.0
-sh-3.00$ id
uid=1050262(cgande1x) gid=1049089(Domain Users) groups=1049089(Domain Users), 65792(+Everyone), 131627(+Remote Desktop Users), 131617(+Users), 1049088(Domain Admins), 131616(+Administrators), 131623(+Backup Operators), 4095(CurrentSession), 66048(+LOCAL), 66820(+INTERACTIVE), 66827(+Authenticated Users)
-sh-3.00$ ls
ls: .: Permission denied
-sh-3.00$ su cgande1x
Password:
sh-3.00$ id
uid=1050262(cgande1x) gid=1049089(Domain Users) groups=1049089(Domain Users), 65792(+Everyone), 131627(+Remote Desktop Users), 131617(+Users), 131616(+Administrators), 131623(+Backup Operators), 66820(+INTERACTIVE), 66829(+TERMINAL SERVER USER), 66827(+Authenticated Users), 66831(+This Organization), 4095(CurrentSession), 1049088(Domain Admins), 1049710(PasswordPropDeny)
sh-3.00$ ls
PUTTY.RND WINDOWS this



Rodney -> RE: permission denied (new to SFU) (Mar. 6, '06, 10:23:13 PM)

> All users manually type their passwords no matter how/where they log in

okay. This plus your su comment indicates that the security token is not getting created in full.
There are two ways for the token to get created. The original port of openssh restricted users to
the disk drives on the local machine. Two years ago I changed that to create a full token so network drives
could be accessed.

I should have asked earlier:
1) Did you install the /Tools openssh package?
2) If yes, which version of openssh are you running? ("pkg_info openssh")



cgande1x -> RE: permission denied (new to SFU) (Mar. 7, '06, 12:37:56 PM)

1) I installed Toolworks 2.0 for SFU 3.5.

2)$ pkg_info openssh
Information for openssh-4.0.0.1.4-bin:

Comment:
Version 4.0.0.1.4 of openssh for Interix 3.5.

Description:
Version 4.0.0.1.4 of openssh for Interix 3.5.
This package was created for the http://www.interopsystems.com/tools web page.



Rodney -> RE: permission denied (new to SFU) (Mar. 7, '06, 2:59:49 PM)

First update to the most current version available.
Do "pkg_update openssh" as either Administrator or someone in the Administrators group.
This will get you to version 4.2. Then try it again.
This way we know you have the most current.



cgande1x -> RE: permission denied (new to SFU) (Mar. 7, '06, 3:08:44 PM)

ftp is not supported in this lab; is there a way around that?



Page: [1] 2   next >   >>



Forum Software © ASPPlayground.NET Advanced Edition 2.5 ANSI

0.094