David Willis writes: > I know this is a somewhat unique and I guess obscure issue, but if someone > could please look into this - I would be very surprised if it was NOT > reproducible following the steps below. Because if this is actually the case > it is in fact granting permissions that it should not be granting to SSH > users that log in using public keys.
You still do not seem to have understood what https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-setuid-overview is trying to tell you. The windows box you log into _must_ have a password for the user that logs into via SSH using one of the methods listed there in order for the user credentials to become valid on the network. > Like I said, there is no error message or anything (due to the nature of the > issue) but the steps to reproduce are as follows: > > Cyg_server is the privileged account used by CYGWIN for SSH privilege > separation, and is a DOMAIN account, and a member of DOMAIN ADMINS Just why do you think that cyg_server should be a domain admin? It only needs local admin membership plus some capabilities that allow it to create a new user token. Does it have those capabilities at all, i.e. what does editrights -lu cyg_server produce as output? If it doesn't have them, then it can't actually switch the user, password or not. > User on the domain (a regular-privileged domain user) logs into another box > on the domain using public key method (NOT password). He logs in as himself, > which has regular non-admin privileges on both the client and server > boxes. Unless that account can authenticate fully on that box (i.e. there's a password), it doesn't have network access. > The client box is either Linux or Windows w/ CYGWIN, but the SSH server must > be CYGWIN. > > After connecting to the CYGWIN SSH server, the user CD's to a Windows server > file share's UNC path - i.e. "cd //[SERVER]/[share]" This would fail if you've not set up cyg_server as a domain admin, if you've even got that far. In fact you'd not be able to use any shares that require authentication. > Now you check Computer Management on the file server, check Shared > Folders->Sessions, and you see that instead of the user having an open > session, the cyg_server user has an open session (from the machine that you > SSH'd to). > > The user now has access to anything that cyg_server would have access to. > Since cyg_server is a domain admin, that would be pretty much everything > aside from shares that are specifically locked down to certain users and not > allowing admins. Don't make cyg_server a domain admin, then. > I don't know if this bug is with SSH or CYGWIN, but it only occurs on CYGWIN > SSH servers (not Linux SSH servers, although its hard to test because when > SSH'd into a Linux box I can't CD directly to a UNC path, I have to mount > the share instead, and specify user credentials to do so). I don't know how you've arrived at the setup you just described, but it's not the one that sshd_host_config produces. Yes, setting up an SSHD wrongly can open up security holes, no surprise here. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
