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/
