Sftp Security - non priv'd user can not connect

[Kumar_Sanjay]

Charlie,

Please turn on the debug. lets see where it is getting stuck.

sftp -vvv username@69.222.73.69

[CharlieCalhoun]

$ sftp -vvv ecp_calhoun@69.222.73.69
Sftp2/SFTP2.C:4804: CRTL version (SYS$SHARE:DECC$SHARE ident) is: V8.3-01

SshFileCopy/SSHFILECOPY.C:1062: Making local connection.
Ssh2SftpServer/SSHFILEXFERS.C:2074: Received SSH_FXP_INIT
Ssh2SftpServer/SSHFILEXFERS.C:2119: version is 3
SshFileCopy/SSHFILECOPY.C:1001: Connection to local, ready to serve requests.
Sftp2/SFTP2.C:786: Connection ready.
SshReadLine/SSHREADLINE.C:3662: Initializing ReadLine...
SshFileCopy/SSHFILECOPY.C:1072: Connecting to remote host. (host = ecp_calhoun@6
9.222.73.69, user = NULL, port = NULL)
argv[0] = /sys$system/tcpip$ssh_ssh2
argv[1] = -v
argv[2] = -x
argv[3] = -a
argv[4] = -o
argv[5] = passwordprompt %U@%H's password:
argv[6] = -o
argv[7] = authenticationnotify yes
argv[8] = ecp_calhoun@69.222.73.69
argv[9] = -s
argv[10] = sftp
Executing ssh2 failed. Command:' /sys$system/tcpip$ssh_ssh2 -v -x -a -o password
prompt %U@%H's password: -o authenticationnotify yes ecp_calhoun@69.222.73.69 -
s sftp' System error message: 'not owner'


%TCPIP-E-SSH_ERROR, non-specific error condition



Example of successful attempt attached.

[Duncan Morris]

Charlie,

there seems to be something fundamentally wrong with the system and/or security setup on the 3 node cluster, judging by the issues with PING and SFTP.

I came across an old "ask the wizard" question that shows the same issue that you describe - but not with sftp.

http://h71000.www7.hp.com/wizard/wiz_7391.html

It looks like sftp/ssh is the victim rather than the culprit here.

Have you tried using

SET WATCH FILE/CLASS=MAJOR

to compare the accesses on the two clusters?
That might help you isolate the issue.

Duncan

[CharlieCalhoun]

Thanks Duncan, maybe this tells me that I have some configuration issue with SSH, rather than a file protection issue.

I'm trying to compare the differences now between the system that works and this one. Haven't found anything glaring yet.

[Kumar_Sanjay]

Charlie,

I just went through your debug output.

=========================================
debug: SshConfig/SSHCONFIG.C:3335: Unable to open ssh2/identification
debug: Ssh2AuthClient/SSHAUTHC.C:374: Method 'publickey' disabled
==========================================
I believe there is some issue in Idenification file under


Its looks like your Idenification permission is incorrect.

or, the file is not present.


Could you please verify the same.

[Willem Grooters]

Since you use multiple system disks: do all of your systems share SYSUAF and RIGHTSLIST? If not, check the VALUES of the UIC's. Although they may look the same in their 'named format', the numerical values may differ: UICGroup for ECP may be 200 on one system and 201 on the other.

[Hoff]

OpenVMS has a longstanding fault in this area: it doesn't check that your core cluster authorization and related files are shared or are coordinated.

The file SYLOGICALS.TEMPLATE has a list of these files that must be shared or must be coordinated.

So what do the privilege audits (alarms) show? Anything?

Duncan: that Ask The Wizard is likely unrelated to this.

[CharlieCalhoun]

Sorry for dropping this for a week, but I got to take some vacation.

Now, I'm back on this. I enabled audit alarms for file access and didn't see squat. I still didn't see anything when trying to issue the TCPIP PING command. Just to make sure I tried to view some files that I didn't have access to and those object access alarms were displayed as expected.

So, I'm thinking more and more that I have a config issue with TCPIP or SFTP or something. I think I'll go ahead and open a ticket on this now. I'll let you all know what the resolution is. Thanks for all the help.

[CharlieCalhoun]

I wrote a little dcl procedure that turned on/off different privs and tried to ping with different privs. Here are the results.



Default privs are...

acnt,cmexec,cmkrnl,group,grpnam,grpprv,tmpmbx,netmbx,prmmbx -

,oper,phy_io



It works with Bypass, Sysnam, and Sysprv. So, Bypass and Sysprv are no surprises, but Sysnam might be telling us that it's failing trying to insert or delete a record into the system logical name table. Does Ping and/or SFTP try to insert or delete entries into the logical name table?



Bingo!!!!



I searched the logical name table to an output file. Then I issued a ping command and listed the contents of the logical name table again while the ping was running and diff'd the system logical name table.



$ show log/table=LNM$SYSTEM_TABLE/out=temp.log

$ show log/table=LNM$SYSTEM_TABLE/out=temp.log

$ diff temp.log

************

File SYS$SYSROOT:[SYSMGR]TEMP.LOG;12

101 "DCL$ATTACH_205ED90E" = "MBA14833:"

102 "DCXSHR_TV" = "DCXSHR"

******

File SYS$SYSROOT:[SYSMGR]TEMP.LOG;11

101 "DCXSHR_TV" = "DCXSHR"

************



Number of difference sections found: 1

Number of difference records found: 1



Ok, so, just to make sure, the process ID for the new logical value does reference the process I was issuing the ping command from.



2-OCT-2008 11:45:09.52 User: SYS_CALHOUN Process ID: 205ED90E



This would probably explain why we were not seeing any audit alarms because I dont think we were watching failures to the logical name table.



I checked the security on the LNT and it looks the same on the systems where it works and those that donâ t.



$ show sec/object=logical_name_table lnm$system_table



LNM$SYSTEM_TABLE object of class LOGICAL_NAME_TABLE

Owner: [SYSTEM_GROUP,SYSTEM]

Protection: (System: RWC, Owner: RWC, Group: R, World: R)

Access Control List:





Now, this reminded me of something the developers had me put in place for one of their Apache processes to work.



$ define/super/table=LNM$SYSTEM_DIRECTORY LNM$TEMPORARY_MAILBOX LNM$SYSTEM



Yes, this is exactly the problem. Because we have a logical defined that points any temporary mailbox logical names into the system logical name table, non privileged users without sysnam fail to successfully issue ping or sftp commands.



Ok, lets look at our options then.



We put this in place so that processes generated by connections to the Apache Web Server could create mailboxes that could also be seen by processes running under a different UIC Group. (please understand Im pulling this from memory when we implemented it several years ago).



CHARLIE CALHOUN APACHE$WWW [373,1] AP_HTTPD All 4 APACHE$ROOT:[000000]

CLIENT LOGIN ACCNT ICS_LOGIN [400,2] ECP All 5 $1$DGA89:[ECP.LIVE.ACS.LOGIN]



So, I know I have a few options.



1. Change the logical back to the way it was. But, this will break our Apache processes. Not really an option.

2. Grant the accounts that need to run sftp SYSNAM. This would probably be acceptable, but not preferred for security.

3. Grant a new identifier to the accounts that use sftp and add a write ACE with that identifier to the system logical name table.

4. Define LNM$TEMPORARY_MAILBOX to point to a different logical name table and configure security so that both UIC groups have write access to that table. This would require us to test our software again.



I implemented option 2 in the short term but I'm going to go with option 3 as a long term solution and document why there is an ACL on the System Logical Name Table in case I die or something.

Thanks for all the help from everyone and sorry for taking so long to get my resolution posted back to the thread.

[Duncan Morris]

Nice work Charlie,

and thanks for posting the details here. It could be a great help to anybody else encountering similar issues.

Duncan