Remote SSH scans doesn't work

[bit-sorcerer]

Basic system information:

Fedora 30, Kernel 5.3.11-200.fc30.x86_64
The openscap daemon is installed on the remote server.

While trying to connect to a CentOS 7 machine I get the following error:

15:38:58
info
SCAP Workbench 1.2.0, compiled with Qt 5.11.3, using OpenSCAP 1.3.1
15:39:06
info
Opened file '/usr/share/xml/scap/ssg/content/ssg-centos7-ds.xml'.
15:41:00
info
Establishing connecting to remote target...
15:41:07
error
Can't connect to remote machine! Exception was: There was a problem with SshConnection! Failed to create SSH master socket! Diagnostic info: Starting process '/usr/bin/setsid --wait /usr/bin/ssh -M -f -N -o ServerAliveInterval=60 -o ControlPath=/tmp/5s8Jfb/ssh_socket -p 22 root@10.100.166.10' Starting process '/usr/bin/setsid --wait /usr/bin/ssh -M -f -N -o ServerAliveInterval=60 -o ControlPath=/tmp/5s8Jfb/ssh_socket -p 22 root@10.100.166.10' stdout: =============================== stderr: =============================== Invalid MIT-MAGIC-COOKIE-1 key (gnome-ssh-askpass:19439): Gtk-WARNING **: 15:41:00.476: cannot open display: :0 Invalid MIT-MAGIC-COOKIE-1 key (gnome-ssh-askpass:19440): Gtk-WARNING **: 15:41:02.784: cannot open display: :0 Invalid MIT-MAGIC-COOKIE-1 key (gnome-ssh-askpass:19441): Gtk-WARNING **: 15:41:05.023: cannot open display: :0 Invalid MIT-MAGIC-COOKIE-1 key (gnome-ssh-askpass:19442): Gtk-WARNING **: 15:41:07.684: cannot open display: :0 Permission denied, please try again. Invalid MIT-MAGIC-COOKIE-1 key (gnome-ssh-askpass:19443): Gtk-WARNING **: 15:41:07.710: cannot open display: :0 Permission denied, please try again. Invalid MIT-MAGIC-COOKIE-1 key (gnome-ssh-askpass:19444): Gtk-WARNING **: 15:41:07.735: cannot open display: :0 Received disconnect from 10.100.166.10 port 22:2: Too many authentication failures Disconnected from 10.100.166.10 port 22

However if I run the dry run i get the following output which works like a charm:

oscap-ssh root@10.100.166.10 22 xccdf eval --datastream-id scap_org.open-scap_datastream_from_xccdf_ssg-rhel7-xccdf-1.2.xml --xccdf-id scap_org.open-scap_cref_ssg-rhel7-xccdf-1.2.xml --profile xccdf_org.ssgproject.content_profile_pci-dss --oval-results --results /tmp/xccdf-results.xml --results-arf /tmp/arf.xml --report /tmp/report.html "/tmp/SCAP Workbench-KbKqWW/ssg-centos7-ds.xml"

Result:

oscap exit code: 2
Copying back requested files...
results.xml 100% 9289KB 43.6MB/s 00:00
results-arf.xml 100% 34MB 85.9MB/s 00:00
report.html 100% 2112KB 57.2MB/s 00:00
%2Fusr%2Fshare%2Fopenscap%2Fcpe%2Fopenscap-cpe-oval.xml.result.xml 100% 82KB 17.6MB/s 00:00
ssg-rhel7-cpe-oval.xml.result.xml 100% 111KB 27.8MB/s 00:00
ssg-rhel7-oval.xml.result.xml 100% 5586KB 72.3MB/s 00:00
Removing remote temporary directory...
Disconnecting ssh and removing master ssh socket directory...
Exit request sent.

Any ideas on what might be going on?

[redhatrises]

Are you using a regular user or root?

[bit-sorcerer]

Hi! i tried to run scap-workbench both as a regular user and as root.

[matusmarhefka]

@bit-sorcerer @redhatrises It seems that scap-workbench does not work with display :1, I suspect there is display number :0 hardcoded in the code.

If you are performing the scan through a remote desktop (vnc), try the following:

1. Edit .vnc/xstartup file in the home directory of your user and add/change this option:
   export DISPLAY=:0
2. Run the vnc server on the display number 0:
   systemctl start vncserver@:0.service
3. Run vncviewer IP:0 and then run scap-workbench remote scan from your remote desktop.

Note: This works for me when using tigervnc-server and it will probably only work when you are not running full desktop on the display :0.

[bit-sorcerer]

Hi, thanks for reaching out! However, I'm not using any remote desktop connections for this. I have scap-workbench installed on my computer, with external monitors attached via a docking station. I've also upgraded and completely reinstalled my computer since I experienced this issue the first time and it still persists.

[cipherboy]

@matusmarhefka Yes, there is indeed a DISPLAY=:0 hard-coded: https://github.com/OpenSCAP/scap-workbench/blob/master/src/RemoteSsh.cpp#L44

I think this was required because setsid strips environment information. Rather than doing it this way, we should probably load the relevant environment variables from well, our environment rather than hard-coding them like this.

[lyraholmes]

Are there any plans to fix this issue?