xfreerdp schlägt fehl remmina geht
Hallo,
seit geraumer Zeit verbinde ich mich erfolgreich mit xfreerdp zu einem
Windows 10 Rechner. Seit gestern geht das nicht mehr. Ich kann nicht
ausschließen, daß auf dem Win10 Rechner irgendwelche Sicherheitsupdates
installiert wurden (habe davon leider keine Ahnung - hier wird viel
automatisch administriert). Der Aufruf mit Trace ist:
~$ xfreerdp /bpp:24 /size:98% /proxy:noproxy /u:domain\ich /v:win10pc:3389 /log-level:TRACE
[08:14:33:010] [239356:239357] [DEBUG][com.freerdp.channels.cliprdr.client] - VirtualChannelEntryEx
[08:14:33:010] [239356:239357] [INFO][com.freerdp.client.common.cmdline] - loading channelEx cliprdr
[08:14:33:011] [239356:239357] [DEBUG][com.freerdp.client.x11] - Searching for XInput pointer device
[08:14:33:011] [239356:239357] [DEBUG][com.freerdp.client.x11] - Pointer device: 10
[08:14:33:013] [239356:239357] [DEBUG][com.freerdp.core.nego] - Enabling security layer negotiation: TRUE
[08:14:33:013] [239356:239357] [DEBUG][com.freerdp.core.nego] - Enabling restricted admin mode: FALSE
[08:14:33:013] [239356:239357] [DEBUG][com.freerdp.core.nego] - Enabling RDP security: TRUE
[08:14:33:013] [239356:239357] [DEBUG][com.freerdp.core.nego] - Enabling TLS security: TRUE
[08:14:33:013] [239356:239357] [DEBUG][com.freerdp.core.nego] - Enabling NLA security: TRUE
[08:14:33:013] [239356:239357] [DEBUG][com.freerdp.core.nego] - Enabling NLA extended security: FALSE
[08:14:33:013] [239356:239357] [DEBUG][com.freerdp.core.nego] - state: NEGO_STATE_NLA
[08:14:33:013] [239356:239357] [DEBUG][com.freerdp.core.nego] - Attempting NLA security
[08:14:33:013] [239356:239357] [DEBUG][com.freerdp.core.proxy] - win10pc => 127.0.0.1 (9)
[08:14:33:013] [239356:239357] [DEBUG][com.freerdp.core.proxy] - win10pc => localhost (9)
[08:14:33:013] [239356:239357] [DEBUG][com.freerdp.core.proxy] - win10pc => domain.local (9)
[08:14:33:013] [239356:239357] [DEBUG][com.freerdp.core.proxy] - win10pc => host1 (7)
[08:14:33:013] [239356:239357] [DEBUG][com.freerdp.core.proxy] - win10pc => host2 (9)
[08:14:33:013] [239356:239357] [DEBUG][com.freerdp.core.proxy] - win10pc => host3 (9)
[08:14:33:013] [239356:239357] [ERROR][com.freerdp.core] - freerdp_set_last_error ERRCONNECT_CONNECT_FAILED [0x00020006]
Ich habe einen Link gefunden[1] wo das Problem mal durch separate Angabe der
Domain verschwand:
~$ xfreerdp /bpp:24 /size:98% /proxy:noproxy /d:domain /u:ich /v:win10pc:3389
[08:21:42:500] [239479:239480] [INFO][com.freerdp.client.common.cmdline] - loading channelEx cliprdr
das hilft also auch nicht (TRACE ist identisch zu oben). In besagtem
FreeRDP bug report[1] wird gesagt, das Remmina funktioniert - in der
Tat, das geht. Insofern möchte ich sagen, daß der Win10 PC zumindest
die Verbindung nicht prinzipiell blockiert. Interessant ist, daß nachdem
ich ~/.config/freerdp gelöscht hatte, xfreerdp dieses Verzeichnis nicht
neu erzeugt. Remmina macht das schon und gibt auch einen Hinweis auf
das Problem:
[08:23:49:449] [240306:240312] [INFO][com.freerdp.client.common.cmdline] - loading channelEx cliprdr
[08:23:49:449] [240306:240312] [INFO][com.freerdp.client.common.cmdline] - loading channelEx drdynvc
[08:23:49:565] [240306:240312] [INFO][com.freerdp.crypto] - creating directory ~/.config/freerdp
[08:23:49:565] [240306:240312] [INFO][com.freerdp.crypto] - creating directory [~/.config/freerdp/certs]
[08:23:49:565] [240306:240312] [INFO][com.freerdp.crypto] - created directory [~/.config/freerdp/server]
[08:23:49:591] [240306:240312] [ERROR][com.freerdp.crypto] - @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
[08:23:49:591] [240306:240312] [ERROR][com.freerdp.crypto] - @ WARNING: CERTIFICATE NAME MISMATCH! @
[08:23:49:591] [240306:240312] [ERROR][com.freerdp.crypto] - @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
[08:23:49:591] [240306:240312] [ERROR][com.freerdp.crypto] - The hostname used for this connection (win10pc:3389)
[08:23:49:591] [240306:240312] [ERROR][com.freerdp.crypto] - does not match the name given in the certificate:
[08:23:49:591] [240306:240312] [ERROR][com.freerdp.crypto] - Common Name (CN):
[08:23:49:591] [240306:240312] [ERROR][com.freerdp.crypto] - WIN10PC.domain.local
[08:23:49:591] [240306:240312] [ERROR][com.freerdp.crypto] - A valid certificate for the wrong name should NOT be trusted!
[08:23:49:591] [240306:240312] [WARN][com.freerdp.crypto] - The VerifyCertificate callback is deprecated, migrate your application to VerifyCertificateEx
[08:24:13:189] [240306:240312] [INFO][com.freerdp.gdi] - Local framebuffer format PIXEL_FORMAT_BGRX32
[08:24:13:189] [240306:240312] [INFO][com.freerdp.gdi] - Remote framebuffer format PIXEL_FORMAT_BGRA32
[08:24:13:189] [240306:240312] [INFO][com.freerdp.channels.drdynvc.client] - Loading Dynamic Virtual Channel rdpgfx
[08:24:13:189] [240306:240312] [INFO][com.freerdp.channels.drdynvc.client] - Loading Dynamic Virtual Channel disp
Scheinbar ignoriert remmina das Problem mit dem Zertifikat, xfreerdp aber nicht.
Also habe ich den xfreerdp Aufruf noch mal mit /cert-ignore sowie /cert-tofu
probiert. Da ändert sich leider auch nichts und ich bin mit meinem Latein am
Ende. Grundsätzlich würde ich lieber xfreerdp per Kommandozeile starten als
den overhead von remmina, um auf den Win10 Rechner zuzugreifen.
Viele Grüße
Andreas.
[1] https://github.com/FreeRDP/FreeRDP/issues/4661
--
http://fam-tille.de
Reply to: