----- "Vagrant Cascadian" <[email protected]> a écrit :
> On Mon, Oct 05, 2009 at 11:24:38AM -0600, David Burgess wrote: > > On Fri, Oct 2, 2009 at 4:40 PM, Vagrant Cascadian > <[email protected]> wrote: > > > essentially, it completely compromises the security of ssh. ssh > and other > > > public-key encryption relies on the fact that the secret key is > actually > > > secret. exporting those secret keys over insecure protocols such > as NBD and NFS > > > compromise that. > > > Are you saying that anybody with network access could get those > keys > > over NBD or NFS? > > yes. Well, are you sure that it gives the access? Listenning to traffic, you can get the content of /root/.ssh/authorized_keys, which is used to validate the key when you try to connect as root. But, As I remember, when you want to export your key pair to a computer, you use "ssh-copy-id -i ~/.ssh/id_dsa.pub" (for example), and not "id_dsa" (which is private). This is the basis of private/public key pair : you actually give your public key, allowing people to ensure that it is *you* that try to connect with your private key. The private key, however, stays on the server (and is not even in the client NBD or NFS image), and when the admin try to connect, it is used by ssh in an encrypted form. In short : if you listen to the network : through NBD or NFS, you get the public root key (useless), while through ssh, you get nothing... And, as ssh is made, even the thin client can't guess the private root key in the authentification mechanism (otherwise, it would be a huge hole in ssh...). I'll be happy to have any confirmation about that, but I'm quite confident their is no security problem in the ssh authentification mechanism :-) However, NFS is known to be unsecure (v3), and one could actually listen to every file that is transmitted by the user (including its ~/.mozilla directory, which may contain passwords). It could even wait for the ".Xautority" file to be transmitted... Actually, remote X is not more secure, so anyone with access to the network may listen to X commands : windows showing, mouse moving, keystrokes.... As a conclusion : NFS and X are unsecure protocols, that can be used in a controlled environment, where you know that one can't plug a laptop as he wishes... Ssh, however, is secure, and relies on private/public keys, so knowing the public environment (the client) won't give access to the admin private informations (private key). > > > Would they need shell access on a PXE-booted machine, > > or would it suffice to use any network-connected machine with NFS > or > > NBD ability? > > they need access to a network-connected machine that has access to the > server > ports running NBD or NFS, such as a laptop they brought with them, or > boot one > of the thin clients from a livecd or usb stick or some other boot > media. > basically, getting a machine plugged into your network that they have > control > over. > > > Personally I don't see this a a significant risk in my environment, > > nor do I see much at stake if somebody did gain ssh access to my > thin > > clients. > > well, if someone gains root access over ssh to your thin clients, and > knew what > they were doing, they would be able to spy on the users of those thin > clients, > possibily gaining access to passwords and other private data. > > they can read all keystrokes, read what's displayed on the X server, > display > windows to the user asking for their password or other sensitive > information, > etc. > > > Nevertheless, I would like to better understand the risk for > > future reference, and I think it bears elucidating for ltsp users > in > > general. > > sure. > > as a general good practice, don't ever give direct root access to > arbitrary > commands, such as a shell. better to restrict to specific commands, > using an > authorized_keys file something like this: > > command="/path/to/some/command --arg1 --arg2" ssh-rsa KEY_GOES_HERE > command="/path/to/some/other/command --arg1 --arg2 --arg3" ssh-rsa > ALTERNATE_KEY_GOES_HERE > > another option would be to give full shell access to a non-root admin > user on > the thin clients with sudo access for specific commands. > > the key is limiting it to specific commands; giving root access to > arbitrary > commands over insecure ssh connections leaves the door wide open to > spy on the > users of the thin clients. > > in the end, it's a risk assesment, and in general it's better to be > overly > cautious. that's my take, anyway. the more you know, the more > terrifying it > gets. :) > > live well, > vagrant > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry® Developer Conference in SF, > CA > is the only developer event you need to attend this year. Jumpstart > your > developing skills, take BlackBerry mobile applications to market and > stay > ahead of the curve. Join us from November 9-12, 2009. Register > now! > http://p.sf.net/sfu/devconf > _____________________________________________________________________ > Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto: > https://lists.sourceforge.net/lists/listinfo/ltsp-discuss > For additional LTSP help, try #ltsp channel on irc.freenode.net ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _____________________________________________________________________ Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto: https://lists.sourceforge.net/lists/listinfo/ltsp-discuss For additional LTSP help, try #ltsp channel on irc.freenode.net
