Nick Jones <[EMAIL PROTECTED]> writes: >> Additionally, dealing with the SSH known hosts file is somewhat of a >> problem. If no additional options are passed to SSH, in many cases it >> is expected that the user would not have added the keys for the relevant >> host to /root/.ssh/known_hosts before running the ebuild command; thus, >> the client would not allow the connection.
> You can write an interface inbetween the eclass and ssh using popen and > forktty. I did this for work. It's fairly aggitating to do, but does > work. forktty opens master and slave pty's and you use the master as > the stderr pipe that communicates with ssh for the password and the > host messages. The data you have to do close() and dup() operations > to get them forwarded to the interface's stdout and stdin. I don't quite see how this would do anything better than what I am currently doing. The issue is not specifying to SSH to ignore that the host is not in the known_hosts file -- that can be done using a simple -oStrictHostKeyChecking=no. The issue is that if special care is not taken, the key is then added to the user's personal known_hosts file, which is probably undesirable. As I state in the message, the solution I employ is to use a temporary known_hosts file. This works fine, except that if the user has specified an alternative location for the known_hosts file in his ssh_config file, the eclass will not copy the alternative file to the temporary location, and so if the user did in fact have the hosts' key in his known_hosts file in an alternative location, the key would not be checked, when ideally it would. All in all though, that seems like a very minor problem. -- Jeremy Maitin-Shepard -- [EMAIL PROTECTED] mailing list
