Restrict SSH or SFTP function, where vms account shares home dir with other users.

[Doug_81]

Hello everyone:
I've been wrestling with the setup of sftp from a vms system to a unix system, utilizing batch mode (e.g. sftp "-B" "filename.com" remoteuser@remotehost.com)

I got it working and now the application support group has given me a list of accounts which require access to this function.

No problem, I simply have to copy the public keys and the identification. file to the ssh2 directory of each user and that's it.

That also works, but here (finally) is the problem.

I have a few hundred users who share the home directory and we want to restrict this function to a few accounts.

Any suggestions?

Here's some technical details:

Client:
HP TCP/IP Services for OpenVMS Alpha Version V5.4 - ECO 6 on a AlphaServer DS15 running OpenVMS V7.3-2

SSH version:
SSH Secure Shell OpenVMS (V5.5) 3.2.0 on AlphaServer DS15 - VMS V7.3-2

Thanks,
Doug

[Hoff]

TCP/IP Services Tips: configuring ssh to disallow sftp and scp access:

http://64.223.189.234/node/347

has details on a couple of means of controlling access.

[Doug_81]

Tried modifying the sshd2.config in sys$sysdevice:[tcpip$ssh.ssh2] with the following line:
SftpDenyUsers username

I then restarted tcpip$client and the username I entered on that line was still able to exectute all of the following:
ssh username@remotehost.com
sftp username@remotehost.com
sftp "-B" "commandfile.com" username@remotehost.com

Doug

[John Gillings]

Doug,

It sounds like the issue here is "share the home directory".

This is often a recipe for management headaches. I'd look at the reasons for this decision, as it can cause many nasty problems to do with file ownership and name clashes (for, example, do your users perform SORTs with default work files? Have you ever had two users SORT simultaneously?)

Assuming you decide you can't give each user their own directory... I'd expect that the keys and identification file are read before LOGIN.COM is executed, so you could create unique, "real" home directories for those users, as defined in the UAF. Then have their "real" LOGIN.COM (ie: the one in their home directory) redefine SYS$LOGIN, SYS$LOGIN_DEVICE and SYS$SCRATCH to point to the common directory, set default there and execute the common LOGIN.COM (even better, leave SYS$SCRATCH pointing at the unique directory to prevent temp files from clashing across users).

From the user's perspective, nothing will be different, but from the system perspective (at least up until LOGIN.COM has completed), they have distinct directories. So, things like SSH, MAIL, SORT and other utilities and applications can continue with their assumptions about unique directory space without problems like the one you describe.

You can distinguish these users because system defined SYS$LOGIN* logical names are EXEC mode, and yours will be SUPER mode, so you can have code which can find the "real" login directory, by requesting an explicit EXEC mode translation.

On the other hand, depending on the way your system is used (captive users?), it may be sufficient to simply SET DEFAULT to the common directory and leave SYS$LOGIN pointing to the unique directory.

[Thomas Ritter]

Doug, if you just want a way to restrict the access then ACL the [.SSH2...] contents.
Something like

$ set file/acl=(id=*,access=none) ssh2.dir
$ set file/acl=(id=user1,a=r+e) ssh2.dir

you get the idea. The [.ssh2] contents provide the keys for non-password batch mode access to the destination host. Got that "non-password" access. The Auditors may spit the dummy on that.

As John has pointed out, sharing the same sys$login will have other problems.

[John Gillings]

Thomas's idea should also work:

>restrict the access then ACL the
>[.SSH2...] contents. Something like
>
>$ set file/acl=(id=*,access=none) ssh2.dir
>$ set file/acl=(id=user1,a=r+e) ssh2.dir
>
>you get the idea

but rather than creating an ACL listing every user, I'd create a general identifier which can be granted to users who require access:

$ MCR AUTHORIZE ADD/IDENT SSH_ACCESS_ALLOWED
$ SET FILE/ACL=(-
(ID=SSH_ACCESS_ALLOWED,ACCESS=R+E),-
(ID=*,ACCESS=NONE)) SSH2.DIR

$ MCR AUTHORIZE GRANT/IDENT SSH_ACCESS_ALLOWED USER1
$ MCR AUTHORIZE GRANT/IDENT SSH_ACCESS_ALLOWED USER2
etc...

[Hoff]

Please confirm this was a Unix server you are targeting and protecting, as your original posting had indicated -- that the modifications were made to the sshd2.config configuration file for the server on OpenVMS seems rather odd, as I'd have expected to modify the config file on the Unix server.

FWIW, all users that share a mutually writable home directory in this fashion on an OpenVMS box are all equally privileged (regardless of what might be in SYSUAF), and all with equal access. Reliable auditing these configurations is a nightmare, too.

[Doug_81]

Thanks for all the responses. Let's see if I can cover them all.

John:
Yes, the issue is the shared home directory. However, this is something that was put in place many years ago (before my time), when it was setup. There are over 1,100 accounts setup this way, and being a production system, that's not going to change. It may not be pretty, but it works. Most (all except a little over 100) of these accounts are locked in the application with the Restricted flag on the account.

Thomas & John:
I thought of acl's but it doesn't work. I don't know if it is becasue the accounts have privileges or it is because they share the home directory.

John: The method you stated re. rights identifiers is what I had tried.

Hoff:
You seem a little confused.
The users are on a vms system using ssh & sftp to connect to a unix system. I had a request to set it up so that certain (vms) users can run a commandfile from a batch job to issue some commands (e.g. ls, put, etc) on a unix system. Since this is being run as a batch job, they want to set it up so that they do not have to put user/password information in an ascii type file (i.e. a command file). I have set it up so that they can use sftp's "-B" batch feature to do this, and it works. The problem now is how to restrict this to only certain accounts when they share a home directory with 1,100 other accounts.

Your comments re. "all users that share a mutually writable home directory in this fashion on an OpenVMS box are all equally privileged (regardless of what might be in SYSUAF), and all with equal access" is likely why acl's do not work in this case.

[Hoff · Accepted solution]

"vms system to a unix system"

If you want to restrict what access into the Unix box is available from OpenVMS, then you set that up on the Unix box.

>>> Your comments re. "all users that share a mutually writable home directory in this fashion on an OpenVMS box are all equally privileged (regardless of what might be in SYSUAF), and all with equal access" is likely why acl's do not work in this case. <<<

ACLs work based on binary identifier values, either assigned to an individual user or to a group of users, or the binary value based on the user's UIC. You might well have 1,100 users with the same UIC here, too.

Restricting client access is not something I usually recommend, as it's often trivial to copy over another client application from another host. It's comparatively weak security.

And as for my cited comments, I mean that all 1,100 people on the OpenVMS box are -- for all intents and purposes -- exactly as privileged as the most privileged user that shares a common login directory. SSH keys and all, most likely. These 1,110 users are likely and effectively identically privileged as that most privileged user, no matter what you've set up in SYSUAF.

With 1,100 users sharing a home directory, attempts to restrict commands seems somewhat of a wasted effort. There are larger issues that would be addressed ahead of restricting individual commands.

Other approaches include web CGI scripts, and setting it up so that only specific users can access the scripts. The scripts would be invoked from Apache or some other server running on the Unix box.

[Doug_81]

Thanks Hoff.
That's good information to have. Nowhere in the VMS documentation or in any of the system management courses I had over the years, has anything said about the hazards of sharing the home directory between accounts.

There is too much risk of things failing in the application if I was to change all 1,100 accounts. They do not share the same uic, btw.

However, I will propose to the application support group, to change the accounts which require the ssh/sftp functionality, so that they have a unique home directory.

Since these are primarily support personel, that shouldn't be a problem.

Thanks to all, for your comments.

Doug

[santoshpandey02]

Hi Doug,

I am not able to transfer file from VMS to Unix server without prompting for password. I have tried SCP2 and SFTP2 both in interactive mode. Can you please provide me the exact steps for creating ids and transferring it to unix server. Also, please mention if any specific setup is required in VMS and Unix server side.

Thanks
Santosh

[Hoff]

Welcome to ITRC.

To implement a no-password login with ssh and public key infrastructure, the sequence is something akin to the following -- details here can vary by source and destination host, and I'm going to assume TCP/IP Services on OpenVMS. (Process has good documentation available for their IP stacks over at their support web site, start at the web page http://www.process.com/techsupport/sshfaq.html)

At its simplest, the no-password login with OpenVMS or Unix or Mac OS X or other ssh implementations means you need to generate a pubic key for your originating system (OpenVMS here), and to then transfer the key over to your target system (the Unix system, here) and register it.

The details on key formats can and does vary by the ssh client (OpenVMS, in this case, though there are multiple TCP/IP stacks on OpenVMS) and the ssh server (Unix, and the particular sshd involved does vary). Put another way, you might have to tweak the following -- but this should get you into the right neighborhood for a Google search or such...

On OpenVMS:

$ set def sys$login
$ @sys$manager:tcpip$define_commands
$ ssh_keygen [.ssh2]keyname

You now have a private keyname. file, and a public keyname.pub file.

Add your keyname.pub file into your local identification file with

$ IdKey keyname

telnet or ssh over to the Unix box.

cd .ssh (or whatever the local box uses)

ftp or sftp or whatever the keyname.pub file, and add it to the list of authorized keys:

ssh-keygen -i -f keyname.pub
>> authorized_keys

Here's another write-up that might help you:
http://ccadmin.uoregon.edu/user_docs/SecureFTP.doc

Stephen Hoffman
HoffmanLabs LLC

--

ps: Santosh, for any future questions you might ask here in ITRC, I'd encourage you to start your own ITRC thread here as this question is apparently unrelated to Doug's original thread -- other than both involve ssh in some fashion.

There are various reasons for starting your own thread here in ITRC, not the least of which is that the thread you've thread-jacked here doesn't have a title related to no-password ssh logins or such -- which means folks might not look here if they do know the answer. You can also mark and manage the threads that you create, too -- "closed", etc. -- which are all tasks that you can't do here in Doug's thread.

And again, welcome to ITRC.