This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ssh, smbntsec, mounted home directory - is it possible


Corinna Vinschen wrote:
> On May 11 00:10, Dave Korn wrote:
>> Andrew DeFaria wrote:
>>>> So to recap: I'd like to provide pre-shared key ssh access to a
>>>> particular username. I cannot, however, use an SMB shared home
>>>> directory for that user without encountering problems with ssh and
>>>> permissions.
>>>>
>>>> If the above statement is not true and you have any ideas on how to
>>>> achieve these objectives then let me know.
>>> Anybody care to comment or at least acknowledge this issue?
>> The above statement is, unfortunately, true. IIUC, until you can use
>> 1.7 with the lsa auth plugin (or perhaps this password caching
>> feature, I'm not familiar with it), any user logging in by ssh key
>> does not really log in as the actual windows user they are trying to
>> be, but impersonates (after some fashion - it might not actually be
>> token impersonation in the win32 api sense of the word) that user,
>> while actually really being the ssh user underneath.
>>
>> I could be wrong. I hope someone will jump in if I've seriously
>> mis-spoke, but I think at least I'm pointing you in the right ball-park.
> It's basically correct but it's a bit more complicated for a weird
> reason which has to do with how Windows handles logon sessions.
> Reading http://cygwin.com/1.7/cygwin-ug-net/ntsec.html#ntsec-nopasswd1
> might
> sched some light.
Thanks Corinna.  This confirms my suspicions and gives all the gory
details. Love it!

There's another drawback for me that's not readily apparent however.

The intent of using a shared home directory in my environment was to
lesson the number of places that the pre-shared keys need to be updated.
Let me explain. What my client is doing is test automation. As such we
need to be able to log into certain Windows boxes that run simulation
software and execute things (Perl scripts) that gather data, etc. To
facilitate this I set up a single user, let's call it tester, with which
the test automation can "login" (ssh, scp, etc.). To make it so that I
didn't have to hardcode tester's password (or otherwise expose it) I
decided to use ssh's pre-shared key. Any of a group of 20-30 test
engineers will use the test automation which in turn uses the pre-shared
key of "tester".

Now for Unix/Linux machine this is not a problem. The test automation
happily ssh's or uses scp to do its thing. But, as I said, there are a
number of Windows boxes with test simulation software that we need to
gain access to.

When the number of boxes was low (say 6-8 of them) I just made local
"tester" accounts with local "tester" home directories. I would then
gather the ssh keys for all testers and combine them together into one
large authenticated_keys file which I would then disseminate to
"tester"'s ~/.ssh/authenicated_keys on the Unix/Linux side (which all
shared one home directory) and then loop through the 6-8 Windows test
boxes with a scp authenticated_keys
tester@<windowbox>:.ssh/authenticated_keys.

But the number of Windows test simulator boxes is now growing. So we got
this bright idea of trying to hook up tester's home directory on
Unix/Linux to the Windows boxes via samba. Theoretically then we would
only need to update one ~tester/.ssh/authenticated_keys and everybody
would be happy. No more skew in the various copies of authenticated keys.

However if I understood the "Method 3 way of logging in without a
password by storing a password" correctly, we'd have to issue multiple
passwd -R commands to the growing (10-15) pool of Windows boxes. If a
new user came in then we'd have to add his password to the 10-15 Windows
boxes. Plus we would have to gain knowledge of all of the users
passwords - something I'm sure they would not like! Finally we have a
password change policy. That'd be a nightmare. With ssh pre-shared keys,
the user can change their password and the pre-shared key doesn't
change. That was nice.

So all in all, this is looking grimmer and grimmer... But at least it's
all documented...
-- 
Andrew DeFaria <http://defaria.com>
Shell to DOS... Come in DOS, do you copy? Shell to DOS...


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]