David Willis writes: > So you're telling me any user that logs in using key authentication cannot > access the network as the same user (i.e. this is the intended behavior)? If > that's the case wouldn't it be better not to allow network access at ALL, > rather than allowing it as the service account that sshd is running as?
You don't have access to anything beyond the machine you've logged into associated with that user account until you create a new logon session for that account on that machine and you need to have the password for this token to be created. The same thing happens if you leave a remote desktop session lingering for a day or so, you will then have to give your password anew since those tokens or rather the Kerberos tickets based on them will expire. If you don't do that, you are still logged into the machine in question and can do pretty much anything there as you are used to, but you are no longer authenticated for network access. > Again, so this is intended behavior when logging in with keys? And > furthermore you are saying the only reason that I have network access as the > cyg_server account is because it is a domain admin, and if it was not, there > would be no network access whatsoever? You could access whatever anybody could access who is authenticated locally or a machine that has joined the domain; that shouldn't be much. But anything requiring more specific access rights associated with your user account would be denied because you're not fully authenticated. > So if I am hearing this right, anyone using SSH with key authentication > instead of password authentication, has NO network access through SSH > sessions at all? That seems unlikely, but if that's the case then so be it. Either that (assuming that you can't use a share that everyone has access to, which is unlikely) or you'd use the "passwd -R" dance, which is iffy in it's own right and certainly not something that you should roll out to just about any machine. Plus all the users have to remember that each time they're changing their passwords they also need to do the "passwd -R" again on each machine they ssh into lest they lock themselves out pretty quickly. Another option is to use password authentication on the first login to each server, then start another sshd as that user from the session just established and then use that secondary sshd with public key login. The secondary sshd would probably have to be restarted after a certain time when the Kerberos tickets expire. > Yes you're right, it is not the one that ssh_host_config produces. > Ssh_host_config would create a SEPARATE local admin account on EVERY box its > run on. That is impractical to manage on a domain and not the setup I want. What you want to do can (and should) be done without giving cyg_server domain admin rights. It needs to be restricted as much as possible, given that it already has some very powerful capabilities. You haven't described the rest of the setup process for sshd on each box, so I won't comment on the practicality of using local accounts anyway. I am quite happy with using a local account since it allows me to give each cyg_server a completely random password that works on just that machine and nowhere else and doesn't need to be recorded anywhere after the services have been installed. > I can assure you I do understand the rights that cyg_server needs to > function, why cyg_server was made a domain admin and why I do not "go with > the default setup that ssh-host-config" provides". However stingy you felt my remark about your application of the domain admin right was, I keep insisting that you shouldn't use it in that way, even if it seems to do what you want. It also does lots of things you absolutely don't want. In fact, there should be no permanently active accounts with domain admin rights anywhere on your network if you care about security. https://technet.microsoft.com/en-us/library/dn487454.aspx https://www.beyondtrust.com/blog/best-practices-for-managing-domain-admin-accounts/ > The one thing I did not > understand was that authenticating with a key was NOT equivalent to > authenticating with a password. That's the whole point of https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-setuid-overview although it may seem somewhat long-winded. If you think that the documentation can be improved, I'm sure Corinna doesn't mind getting a patch. > I now understand that fact - I would now > suggest that in the documentation you explicitly point out that when logging > in w/ key auth, you have the rights on the network that cyg_server has. I > don't think that point is explicitly made in the documentation, and I don't > think it would be a bad idea to do so. That may actually be an unintended consequence of how Windows deals with the Kerberos tickets that govern network access and should be considered a bug. I'm not sure if or how that can be avoided, but it would be nice if sshd did not present those tickets at all. But there wouldn't have been a valid ticket to present if you hadn't made cyg_server a domain admin. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf microQ V2.22R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada -- 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
