From: Alkis G. <al...@gm...> - 2013-07-24 05:23:03
|
Στις 24/07/2013 01:03 πμ, ο/η Jakob Unterwurzacher έγραψε: > This means that you won't know the client ssh host key. That's not > better than a publicly-known one - either way you can't be sure the box > you are connecting to is not spoofed. Not knowing the ssh server public key == trust issue (for the first connection). Also, if anyone (with e.g. a laptop) can read the ssh server private key via the NBD connection, then he can use it for his own ssh server, so "knowning the chroot ssh server public key" == completely useless. On the other hand, knowing the ssh server private key == privacy issue (for all connections). For example, if I connect to some ssh server and an eavesdropper that has access to the server private key is listening, I believe that he can then monitor the keystrokes (passwords etc) that I type into the ssh shell. > > Make sure you are using key-based authentification to log into the thin > clients. Never use passwords in the thin client - its /etc/shadow is > also publicly viewable, and can be used to crack your password. This > could then be used to log into thin clients and install keyloggers etc. > > If done that way I don't see any security issues, even with shared ssh > host keys. If my assumption above is true, that a leaked ssh server private key means that the ssh connections are no longer private, then this applies to key-based authentication as well. One other possible implementation that I was thinking of, would be to use some values that are unique for each client as the random seed for the ssh private keys. For example, the client MAC, its output of `dmidecode` etc. Then the LTSP client ssh server host keys would always be the same, and the sysadmin would only need to trust them once. |