On Tue, Oct 06, 2009 at 09:03:24AM +0200, Frédéric Grelot wrote: > ----- "Vagrant Cascadian" <vagr...@freegeek.org> 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 > > <vagr...@freegeek.org> 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?
yes. > 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. the keys i am talking about are usually located in /opt/ltsp/i386/etc/ssh/*host*key*, which is exported via NFS or NBD. those are the host's private/public keypairs, which are used to establish that you're connecting to the machine you think you are, and prompts you with messages such as this: $ ssh somerandomhost The authenticity of host 'somerandomhost (127.0.0.1)' can't be established. RSA key fingerprint is 05:e4:5e:f6:2a:6e:9c:47:50:45:67:bc:f8:eb:8a:58. Are you sure you want to continue connecting (yes/no)? since all thin clients use the same host key, someone could play a man-in-the-middle attack when you ssh to the thin client, as you have no means of determining which thin client you're connecting to, and relay the session to the real thin client, and listen in on the whole ssh session. and if you ssh to the thin client as root, they gain root access to the thin client. > 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... in LTSP, you don't usually mount /home over NFS, you log into the application server and file access happens on the server. the programs are merely displayed on the thin-client. > Actually, remote X is not more secure, so anyone with access to the network > may listen to X commands : windows showing, mouse moving, keystrokes.... which is why LTSP5 uses ssh's X11 forwarding... though you have similar security concerns to the above man-in-the-middle attack, as the thin-client's /etc/ssh/known_hosts is going over a shared NFS/NBD connection. so it can't *securely* determine that the server is actually the server you think you're connecting to. > 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). as long as you don't export private *host* keys over insecure methods, yes. :) live well, vagrant ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) 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/devconference _____________________________________________________________________ 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
