On 18/10/2013 04:30, Walter Dnes wrote: > On Thu, Oct 17, 2013 at 08:59:15AM +0200, Alan McKinnon wrote > >> Accessing the actual backend network is a two stage process: ssh key to >> the jump host, then password to get onto the actual destination. >> >> So it's "two factor" as a generic English language phrase, not "two >> factor" as a technical description of an exact thing. Keep in mind that >> English is a highly overloaded language :-) > > I apologize. That is arguably a two factor system. When you said > "ssh key and password", I "jumped to delusions", assuming that it was a > standard ssh connection with the option of either key or password. Does > the jump host restrict you to logging on to the account corresponding to > the key? I.e. would John Smith got to the jump host with his key, could > he log in to the Jane Doe account, or only John Smith.
I built it myself, so I done did it rite :-) It's very much one key to one user and the only jump host the general user (i.e. customer support) can use is the main advertised one. Infrastructure people and my friends in NetOps have other ways of getting into the network but those are very restricted access. When building this, we found something interesting - dudes were sharing keys. The mind boggles as to why anyone thought this a good idea but that's what they were doing. I suspect some people found ssh-keygen and/or PuTTY too difficult to wrap their wits around. But the fix was simple - with 700+ users and 250+ hosts to manage, we do user deployment centrally with no way to bypass it. The database field containing the public key string was given a unique index. No more duplicate keys :-) -- Alan McKinnon alan.mckin...@gmail.com
