[libvirt] [RFC] Use libssh2 for ssh transport instead of forking ssh process.

[Peter Krempa]

The current state of the ssh transport involves starting the ssh client 
process
(command ssh) that communicates using pipes and a socked with the 
libvirt client.
Thereafter it behaves as a standard virNetSocket. This configuration has 
some
drawbacks, but changing the ssh transport to libssh2 could break some users
configurations.

My concern is, that someone might be using advanced configurations of ssh
done via the ssh config file, and removing this "old" way to do it would 
break it.
Libssh2 does not use any configuration files, but is configured using 
the API.
The URI scheme we are using now allows to specify configuration of the 
transport layer
using parameters. In my opinion, this would be a nice way how to set 
configs on a
per-connection basis, but would not take into account default 
configurations the users
are familiar with, while using ssh.

Advantages of using libssh2:
- no need to spawn external process and comunicate through pipes (with 
all scheduling
   benefits)
- multi platform support (should provide ssh support on m$ windows)
- allow to configure transport connection using the uri
- use auth callbacks to query for passwords/passphrases (no ssh-askpass)
- control over error messages
- nicely integrates with virNetSocket, as open socket must be provided 
to libssh2 to
   work on.

Disadvantages:
- break configurations for users that use advanced ssh configurations in 
the ssh client
   config file

Possible implementation options:

1.) Add libssh2 support as a new transport option ( 
qemu+libssh2://user at host/system )
2.) Use libssh2 as the default ssh transport provider and move old ssh 
stuff to a new
     transport option ( qemu+cmdssh://user@host/system, or similar)
3.) Drop old ssh completly and get mauled by users :/
4.) Leave it in current state.
5.) Add the choice on compile time.

I think, that the most favourable option is 2.) as it retains the old 
way for users that
have configured it to work for them, and adding some letters to the uri 
would be less
painfull for them and at the same time prefers the new api for new 
configurations as
the default. Option 1) includes the risk, that tie change to the new api 
would be ignored,
as nearly everybody would not care about changing their URIs even if it 
would not break
anything. The two other options (not counting leaving it as-is) are 
really bad in my opinion.

I'd like to have your opinions on changing the ssh transport provider.

Thanks.

Peter