On Sat, December 2, 2006 8:26 am, Stewart Stremler wrote: > begin quoting guy keren as of Sat, Dec 02, 2006 at 02:51:32PM +0200: >> >> On Sat, 2006-12-02 at 00:05 -0800, Tracy R Reed wrote: >> > Gabriel Sechan wrote: >> > >> From: "Lan Barnes" <[EMAIL PROTECTED]> >> > >> On Fri, December 1, 2006 1:32 pm, Gabriel Sechan wrote: >> > >>> Not allowed by the security team, or I would. >> > >> > This doesn't reflect well on the security team IMHO. I have seen >> > environments where ssh keys were not welcome also and it always came >> > from a lack of understanding how the keys work. >> > >> > > for just getting it done than to get reprimanded. Besides, I >> > > think the real issue the security team had was that noone was >> > > typing passwords to do it. We still use ssh daily, just not >> > > passwordless or key based ssh. >> > >> > The right way to use ssh-keys is with ssh-agent. With ssh-agent you >> have >> > to enter the password once to decrypt you key which is held in memory >> > and only child processes of ssh-agent have access to it. More secure >> > than an potentially guessable normal passworded login. >> >> i think that the problem with this setup, is that the security people >> have no way to enforce that you create a key with a pass-phrase. once >> they allow you to use ssh keys, it is up to you (the user) whether or >> not to use a pass-phrase. at least that was the situation with sshd in >> the past - i don't know if this issue was resolved yet. > > Indeed. The security person isn't being stupid -- they can deal with > the slightly increased risk of having potentially guessable passwords, > over which they have some control (to let them mitigate the risk), > but they have no control over the creation of passphrases, much less > the quality of passphrases, thus no way to mitigate that risk. > >> so you see - the problem is of trusting your users. when did you last >> meet a security person (and in a corporate) that trusts her users? > > When has a security person ever been able to trust a corporate user? > > Sure, they can trust _some_, but they have to set a policy, and the > policy has to work for _all_ of their users. Including the idiotic > ones, or the forgetful ones ( who walk away from their terminal ), etc. > > [
But here's my problem. If the password is in the expect script, then they have to trust the users to lock up read on the script. 'Course, Gabe was talking about hacking a little interface to request the password, but that's happening in user space, subject to swap (hard to see that happening, but it could), etc. So they're trusting at the least Gabe on expect and maybe their users, too. -- Lan Barnes Tcl/Tk Enthusiast SCM Analyst Linux Guy Biodiesel Brewer -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
