Hide Forgot
Description of problem: there have some issue when connections over SSH with SPICE Version-Release number of selected component (if applicable): spice-glib-0.6.2.el6.x86_64 spice-gtk-0.6.2.el6.x86_64 virt-viewer-0.4.0-2.el6.x86_64 spice-server-0.8.1-2.el6.x86_64 How reproducible: always Steps to Reproduce: 1:install a guest with spice of display. 2:virsh dumpxml demo ..... <graphics type='spice' port='5900' tlsPort='-1' autoport='yes' listen='0.0.0.0'/> ..... 3:virsh start demo 4:use --connect option to connect guest #virt-viewer --connect qemu+ssh://10.66.6.166/system demo --debug ** (virt-viewer:23774): DEBUG: Opening connection to libvirt with URI qemu+ssh://10.66.6.166/system ** (virt-viewer:23774): DEBUG: Add handle 4 1 0x17bd0f0 root.6.166's password: ** (virt-viewer:23774): DEBUG: Add timeout 0x17bcae0 -1 0x30a94c6b60 0x17a8b20 1 ** (virt-viewer:23774): DEBUG: Guest demo is running, determining display ** (virt-viewer:23774): DEBUG: Guest demo has a spice display ** (virt-viewer:23774): DEBUG: Guest graphics address is 0.0.0.0:5900 ** (virt-viewer:23774): DEBUG: Opening indirect TCP connection to display at 0.0.0.0:5900 ** (virt-viewer:23774): DEBUG: Setting up SSH tunnel via (null)@10.66.6.166:22 root.6.166's password: ** (virt-viewer:23774): DEBUG: main channel: opened ** (virt-viewer:23774): DEBUG: new session channel (#0) (virt-viewer:23774): GSpice-WARNING **: (channel-main.c:1140):_channel_new: runtime check failed: (channel != NULL) ** (virt-viewer:23774): DEBUG: new inputs channel ** (virt-viewer:23774): DEBUG: Display size request 50x50 (desktop 100x100) ** (virt-viewer:23774): DEBUG: Allocated 400x375 ** (virt-viewer:23774): DEBUG: Child allocate 375x375 root.6.166's password: root.6.166's password: root.6.166's password: Permission denied, please try again. root.6.166's password: root.6.166's password: Permission denied, please try again. root.6.166's password: Permission denied, please try again. root.6.166's password: Permission denied, please try again. root.6.166's password: Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password). Actual results: input password many times,graphic display but can't login guest, virt-viewer hang. Expected results: graphic console will displayed and can login guest. Additional info: in same environment, use virt-viewer demo , the graphic console can display and login the guest use SSH with vnc to connect other guest in the same hypervisor can work well.
in same enviroment, use command: #virt-viewer --direct -c qemu+ssh://10.66.6.166/system demo --debug it can worked well.
Your SSH client is prompting for passwords, which suggests you don't have any SSH keys + ssh agent configured. It is not really practical to support SSH passwords with SPICE, since a connection to the SPICE server requires about 8 TCP connections. This is why you see soo many password prompts. Can you configure an SSH AGENT + public keys and then re-test remote access.
Hi Daniel: I cnfig SSH keys , and re-test, it worked well. configure SSH public keys #ssh-keygen Generating public/private rsa key pair. Enter file in which to save the key (/root/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /root/.ssh/id_rsa. Your public key has been saved in /root/.ssh/id_rsa.pub. .......... #ssh-copy-id -i /root/.ssh/id_rsa.pub root.6.166 then test remote connect #virt-viewer -c qemu+ssh://10.66.6.166/system demo --debug it can worked as expect,so is it the different behavior with vnc?if yes,i will close this bug and write new test cases for this. and i have an additional question:Does spice support TLS/TCP connection? like -c qemu+tls://$ip or -c qemu+tcp://$ip ?please help confirm , thanks in advance.
Yes, this is different behaviour than with VNC, because VNC only uses a single SSH connection, while SPICE requires multiple. Yes, SPICE does support TLS & TCP connection URIs with libvirt.
thanks your response, i test TLS & TCP URIs for spice and spice with multihead, all work now, i will write new test cases for this.
(In reply to comment #3) > it can worked as expect,so is it the different behavior with vnc?if yes,i will > close this bug and write new test cases for this. Closing as NOTABUG.