expertenaustausch > linux.debian.user.german

Andreas Tille (28.04.2020, 09:00)
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]
Martin Reising (28.04.2020, 12:00)
On Tue, Apr 28, 2020 at 08:52:51AM +0200, Andreas Tille wrote:
> [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 hostnameused 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


Die Fehlermeldung ist unmissverständlich, wenn man den Unterschied
zwischen FQDN und Hostnamen kennt.

win10pc ist zwar das Gleich wie win10pc.domain.local, aber eben nicht
das Selbe!

Die Fehlermeldung sollte nicht auftreten wenn du dich mit
win10pc.domain.local verbindest, statt mit win10pc.
Andreas Tille (29.04.2020, 08:20)
On Tue, Apr 28, 2020 at 11:27:50AM +0200, Martin Reising wrote:
> On Tue, Apr 28, 2020 at 08:52:51AM +0200, Andreas Tille wrote:
> Die Fehlermeldung ist unmissverständlich, wenn man den Unterschied
> zwischen FQDN und Hostnamen kennt.
> win10pc ist zwar das Gleich wie win10pc.domain.local, aber eben nicht
> das Selbe!


Das ist mir bekannt.

> Die Fehlermeldung sollte nicht auftreten wenn du dich mit
> win10pc.domain.local verbindest, statt mit win10pc.


Die Fehlermeldung die Du zitierst, ist leider nicht relevant, denn trotz
des Fehlers an der Konsole kann remmina sich ja verbinden. Bei xfreerdp
was ich gern zum laufen brächte tritt *diese* Fehlermeldung nicht auf
und das Ergebnis ist mit und ohne Domain identisch: Es funktioniert
nicht.

Viele Grüße

Andreas.
Thomas Schöpfer (29.04.2020, 18:00)
Am 28.04.20 um 11:27 schrieb Martin Reising:

> Die Fehlermeldung ist unmissverständlich, wenn man den Unterschied
> zwischen FQDN und Hostnamen kennt.
> win10pc ist zwar das Gleich wie win10pc.domain.local, aber eben nicht
> das Selbe!
> Die Fehlermeldung sollte nicht auftreten wenn du dich mit
> win10pc.domain.local verbindest, statt mit win10pc.


xfreerdp hatte bei mir noch nie ein Problem mit falschen Hostnamen im
Zertifikat. Daran sollte das nicht liegen.
Vor ca. 3 Monaten fing allerdings das Problem an, dass aktuelle Windows
10 VMs jeweils beim 2. Anmelden mit xfreerdp abgestürzt sind. Mit
Remmina passiert das nicht. Deshalb nutze ich nun nur noch das.

Grüsse
Thomas
Ähnliche Themen