Sftp Security - non priv'd user can not connect

[CharlieCalhoun]

Put this in System Management rather than networking since the problem seems to be related to resource security rather than network.

OpenVMS 8.3
TCPIP 5.6 ECO2

When attempting to connect to a remote host via SFTP with a privileged account, the connection works fine.
When attempting to connect with an unprivileged account, the connection attempt results in the following error...

_____
sftp> open 69.222.73.69
Opening connection to 69.222.73.69
Executing ssh2 failed. Command:' /sys$system/tcpip$ssh_ssh2 -x -a -o passwordprompt %U@%H's password: -o authenticationnotify yes 69.2
22.73.69 -s sftp' System error message: 'not owner'

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

I can grant the unpriviliged user SYSPRV and they can connect normally.

I would guess that I need to relax security on a file, but I don't know where to look.

Here's what I've checked so far.

Directory SYS$COMMON:[SYSEXE]

TCPIP$SSH_SSH2.EXE;1
(RWED,RWED,RE,RE)

Directory $1$DGA86:[SYS0.SYSMGR.ssh2.hostkeys]

KEY_22_69_222_73_69.PUB;1 [SYSTEM_GROUP,SYSTEM] (RWED,RWED,RE,RE)
(added G:RE and W:RE) but that didn't make any difference)

Then I realized the user had their own key, so checked the protection on that file and it looks fine.

Directory $1$DGA80:[ECP.MANAGER.ssh2.hostkeys]
KEY_22_69_222_73_69.PUB;1 [ECP,*] (RWED,RWED,RWED,R)


Anyone have any idea where I might need to look next. I need this to work for this user without having to grant them SYSPRV.

Thanks for the help.

[Duncan Morris]

Charlie,

I would be very careful to make sure that the ID of the directory tree [.ssh2...] matches the username exactly.

We have discovered that if you have a username JOE with an ID of FRED say,

UAF> sh joe

Username: JOE Owner: SSH example
Account: UIC: [245,2727] ([ISE,FRED])

then sftp will crash with an ACCVIO, even though the files are all owned by [ISE,FRED].

Remove Id FRED and replace it with JOE, and then sftp works correctly.

So, sftp is very sensitive to the combination of username and identifier. I wonder if this may be the source of your problem?

I see that the owner of the hostkey is [ECP,*] - not matching whatever username the unprivileged user has.


Duncan

[Jon Pinkley]

Duncan,

Have you openned a case with HP concerning your finding? That seems like a bug to me. The program should not assume the text name of the "user identifier" (the identifier associated with the UIC of a user) is identical to the USERNAME.

Jon

[CharlieCalhoun]

Hmm. That's interesting. In my situation, all members of the [ECP,*] group share a SYS$LOGIN directory. They do have separate UIC's.

After posting, I continue to look for results elsewhere and realized that I may have a configuration issue within the SSHD2CONFIG file. I'm using the default and have not modified it. Here are the entries that, as I understand it, may have an impact on my situation. Notice most are all commented out.

# SftpDenyUsers username1.*,username2

## User restrictions

# AllowUsers sj.*,s[[:digit:]]*,s(jl|amza)
# DenyUsers skuuppa,warezdude,31373
# DenyUsers don@untrusted\.org
# AllowGroups staff,users
# DenyGroups guest,anonymous
PermitRootLogin yes
# PermitRootLogin nopwd

Could it be that I need to uncomment the AllowUsers parameter? Is the default Allow or Deny? I've concatenated the SSH2_CONFIG and SSHD2_CONFIG files attached them here proactively.

[Jan van den Ende]

Charlie,

>>>
That's interesting. In my situation, all members of the [ECP,*] group share a SYS$LOGIN directory. They do have separate UIC's.
<<<
Have you tried giving those users GRPPRV i.o. SYSPRV?
Mind, that will NOT be THE solution, but it might be a workaround for the time being.

Worth a try?

Just my EUR 0,002

Proost.

Have one on me.

jpe

[CharlieCalhoun]

Duncan, I thought we might have been on to something there for a minute. But after testing, I proved that not to be the case. I created a new account and ensured that it had a sys$login that was owned exactly the same as the UIC. Still no luck. I get the same error back.

Jan, all of these accounts have GROUP, so I tested with one after giving it GRPPRV with no change in the results.

Thanks for the help. I'll keep searching.

[CharlieCalhoun]

More info.

5 node cluster. 2 nodes share one system disk, dga83. The other 3 share a different system disk, dga86.

I can successfully connect via sftp using these accounts from the 2 node cluster booted from dga83. Using the same accounts, I can not connect from the systems booted from dga86.

This got me to thinking that I may have had a difference between the config files for SSH. But, no luck there. They are both the same.

This may actually be a more general issue. While troubleshooting this, I discovered that while I can ping systems from these unprivileged accounts on the 2 nodes booted from DGA83, I can not ping anything from the 3 nodes booted from DGA86. I get the following error.

TCPIP> ping lyra.tns.ndchealth.com
%TCPIP-E-LOOPERROR, error processing loop request
-SYSTEM-F-NOPRIV, insufficient privilege or object protection violation

It may just be time to log a case with HP.

[Hoff]

Do you have the ssh client and server stuff enabled in TCPIP$CONFIG, et al?

[CharlieCalhoun]

Yes. It works with accounts that have SYSPRV, but wont work without it.

[Hoff]

Turn on the use-of-privileges security auditing (alarms), try it from a privileged username, and see what pops out with security audits (alarms).

That shared access stuff is arguably a problem; group accounts are bad for accountability, no matter how you structure them.

[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

[CharlieCalhoun]

Resolution already posted.