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.