[libvirt] [RFC] Use libssh2 for ssh transport instead of forking ssh process.
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@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
Hi Peter,
Disadvantages: - break configurations for users that use advanced ssh configurations in the ssh client config file
Whenever I had a look at native ssh libraries in Perl or Python I found GSSAPIAuthentication was not supported. My favorite ist solution one, a new transport option for libssh2. I could live with option two. Kind regards! -- Matthias Witte - witte@netzquadrat.de Telefon: +49 (0)211-30 20 33-18 Telefax: +49 (0)211-30 20 33-22 [netzquadrat] GmbH - Gladbacher Str. 74 - 40219 Düsseldorf HRB Düsseldorf 36121 - Geschäftsführer: Thilo Salmon, Tim Mois Steuernummer: 106/5719/1836, Umsatzsteuer-ID: DE246863050
On Tue, Oct 18, 2011 at 11:29:46AM +0200, Peter Krempa wrote:
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.
There's no question that libssh2 is very compelling becuase it lets us integrate with the authentication callbacks.
Possible implementation options:
1.) Add libssh2 support as a new transport option ( qemu+libssh2://user@host/system )
This one makes most sense
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 :/
Both 2 & 3 are not practical. Users will hunt us down & beat us with big sticks, if we break their existing URIs.
4.) Leave it in current state. 5.) Add the choice on compile time.
Compile time switches for this would not really work. We'd want to enable libssh2 in Fedora, and then we're back to problems of option 2.
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 don't think we need to worry about forcing people to use the new transport. Applications which actually want the enhanced auth integration support can choose to use the libssh2 URI. Other people don't need to change unless they desire it Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
participants (3)
-
Daniel P. Berrange -
Matthias Witte -
Peter Krempa