Ошибка подключения к серверу единой регистрации ubuntu

Перейти к контенту

  • Печать

Страницы: 1 [2] 3  Все   Вниз

Тема: remmina ошибка «Невозможно подключиться к серверу RDP» при подключении к windows  (Прочитано 52837 раз)

0 Пользователей и 1 Гость просматривают эту тему.

Оффлайн
Leo_87

1) грохнуть ~/.freerdp
2) проверить под другим пользователем

Грохнул.
Под другим пользователем заходит, а как под тем который нужен зайти?


Оффлайн
ArcFi

Leo_87, удаление ~/.freerdp помогло?


Оффлайн
Leo_87

Leo_87, удаление ~/.freerdp помогло?

Помогло на одной машине.
На других удалил, под другим пользователем пускает. Но под тем который нужен не хочет.
Что ещё можно посмотреть?


Оффлайн
ArcFi

Leo_87, там, где не работает, показывайте:

cat /etc/issue
nmap -Pn -sV -p PORT IP
PORT — RDP-порт, обычно 3389
IP — адрес RDP-сервера


Оффлайн
Leo_87

Leo_87, там, где не работает, показывайте:

Starting Nmap 5.21 ( http://nmap.org ) at 2013-07-18 11:13 MSK
Nmap scan report for 192.168.0.9
Host is up (0.00066s latency).
PORT     STATE SERVICE       VERSION
3389/tcp open  ms-term-serv?

Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 99.19 seconds


Оффлайн
Leo_87

Проблему решил.
Помимо папки ~/.freerdp , нужно удалить все файлы из папки ~/.remmina
Спасибо за помощь.


Оффлайн
ArcFi

В ~/.remmina лежит конфиг и настройки всех подключений, с этим надо аккуратнее, а то можно наудалять лишнего.


Оффлайн
sergicus

у меня была похожая проблема.
Решил — помогло — в настройках профиля подключения -> дополнительные -> безопасность , в этом пункте установить вместо автосогласования RDP


Оффлайн
Ods

у меня была похожая проблема.
Решил — помогло — в настройках профиля подключения -> дополнительные -> безопасность , в этом пункте установить вместо автосогласования RDP

Огромная благодарность автору поста! Несколько дней была лишена доступа к работе, куча нервов и времени, нигде и ничего толкового, все удаляла, чистила, грузила заново — эффекта 0 и только ваша подсказка за секунду решила все проблемы!!! Спасибо форуму и автору sergicus!


Оффлайн
vadimvolodin

как то давно ремина начала глючить, не когда было разбираться поставил KRDC и забыл про ремину.


Оффлайн
Storke

у меня была похожая проблема.
Решил — помогло — в настройках профиля подключения -> дополнительные -> безопасность , в этом пункте установить вместо автосогласования RDP

Благодарю за помощь! Тоже мучился полдня. Remmina без проблем подключалась из Ubuntu 14.04 к Windows Server 2008 R2 в роли сервера терминалов. Как только создал домен, убрав сервер терминалов, возникла та же байда. После выбора вместо Согласование RDP снова смог подключиться.


Оффлайн
serp53

Всё опробовал что указано выше в топике и не помогло.
Предыстория. У меня раньше терминальный сервер (Windows server 2008 R2) был не в домене и всё работало, по производственной необходимости пришлось терминальный сервер подключить к домену. После подключения «Remmina» отказалась подключаться к терминальному серверу (Windows server 2008 R2).
В моём случае, после того как поставил галочку «Прикрепить к консоли (windows 2003 / 2003 R2)» «Remmina» стала подключаться.


Оффлайн
kac

Кстати очень много проблем решает remmina ppa. Каждую неделю есть обновления.много проблем решилось.


Оффлайн
jenkidu

Была точно такая же проблема. На сервер с винды по RDP зайти могу, с Ubuntu 14.04 не могу (невозможно подключиться к серверу RDP).
Удаление папки .freerdp помогло.
Заново выдался сертификат, все заработало.


Оффлайн
guertauli

Заново выдался сертификат, все заработало.

Что-бы сертификат не прописывался никогда:
1. Удалить все содержимое внутри папки .freerdp
2. chmod u-w .freerdp

« Последнее редактирование: 08 Марта 2016, 18:59:34 от guertauli »


  • Печать

Страницы: 1 [2] 3  Все   Вверх

I recently upgraded my Ubuntu to 18.04, and now my Remmina cannot connect to a windows server we use at work. Now I am getting a popup about certificates. It asks if I want to accept the certificate, I click OK and then get a message saying unable to connect. I am getting this error on the command line:

[14:49:19:412] [7223:7537] [INFO][com.freerdp.client.common.cmdline] - loading channelEx cliprdr
[14:49:19:412] [7223:7537] [INFO][com.freerdp.client.common.cmdline] - loading channelEx drdynvc
[14:49:19:909] [7223:7537] [ERROR][com.freerdp.crypto] - @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
[14:49:19:909] [7223:7537] [ERROR][com.freerdp.crypto] - @           WARNING: CERTIFICATE NAME MISMATCH!           @
[14:49:19:909] [7223:7537] [ERROR][com.freerdp.crypto] - @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
[14:49:19:909] [7223:7537] [ERROR][com.freerdp.crypto] - The hostname used for this connection (xxxxx:3389) 
[14:49:19:909] [7223:7537] [ERROR][com.freerdp.crypto] - does not match the name given in the certificate:
[14:49:19:909] [7223:7537] [ERROR][com.freerdp.crypto] - Common Name (CN):
[14:49:19:909] [7223:7537] [ERROR][com.freerdp.crypto] -    EC2AMAZ-FM25IO2
[14:49:19:909] [7223:7537] [ERROR][com.freerdp.crypto] - A valid certificate for the wrong name should NOT be trusted!
[14:50:38:624] [7223:7537] [ERROR][com.freerdp.crypto] - certificate not trusted, aborting.
[14:50:38:624] [7223:7537] [ERROR][com.freerdp.core] - freerdp_set_last_error ERRCONNECT_CONNECT_CANCELLED [0x0002000B]
[14:50:38:624] [7223:7537] [ERROR][com.freerdp.core.connection] - Error: protocol security negotiation or connection failure
0002000B 00000003

Now this is an internal vpn server so I don’t care at all about certificates. Is there a way to add this certificate to a list that it’s ok? How do I get around this? And as an aside, this was working before the upgrade just fine. I don’t know why it cares now?

asked May 23, 2018 at 18:58

mmaceachran's user avatar

4

I had the same problem on debian sid with latest remmina 1.2.32.1 while connecting to a windows server2008r2 with hardend security settings.

I was able to connect after:

  • updating all freerdp2 libraries (used by remmina) to 2.0.0~git20181120.1 version
  • removing ~/.config/freerdp/known_hosts2 file

The connection security type that worked is «NLA» (negotianion/auto-detection worked too).

Both TLS and RDP didn’t work.

answered Jan 10, 2019 at 20:08

Vasily Galkin's user avatar

2

I’ve found the solution @Ubuntu forums, that forked for me :)

You have to change the Security to «TLS» in the Advanced tab of your connection, and everything works fine!

answered Jul 2, 2018 at 13:15

Vasily's user avatar

3

with RDP connections I get a TLS connection error, you have to look to the correct TLS version:

for me the solution was other way around:

I have to change the Security to «RDP» in the Advanced tab of your connection, and everything works fine!
( I work with debian 10 buster (sid) and remmina 1.2.32)
regards,
from germany

answered Oct 27, 2018 at 13:37

GerdPeter's user avatar

1

I’ve hit the same problem connecting from one of the Ubuntu/Debian family distributive to MS Windows Server 2008 R2.

I managed to solve it this way:

  1. Create new connection with server.name.or.ip:port in Server section (port is optional if u haven’t changed it from standard MS RDP 3389 or/and NATed it through a router if u have one)

  2. In the Advanced tab set
    -«Security protocol negotiation» to «NLA protocol security»
    -«TLS Security level» to «0 — Windows 7 compatible»

Then Remmina only asked me once about accepting the certificate and now it works like a charm.

answered Jul 15, 2022 at 22:07

coldfix's user avatar

I recently upgraded my Ubuntu to 18.04, and now my Remmina cannot connect to a windows server we use at work. Now I am getting a popup about certificates. It asks if I want to accept the certificate, I click OK and then get a message saying unable to connect. I am getting this error on the command line:

[14:49:19:412] [7223:7537] [INFO][com.freerdp.client.common.cmdline] - loading channelEx cliprdr
[14:49:19:412] [7223:7537] [INFO][com.freerdp.client.common.cmdline] - loading channelEx drdynvc
[14:49:19:909] [7223:7537] [ERROR][com.freerdp.crypto] - @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
[14:49:19:909] [7223:7537] [ERROR][com.freerdp.crypto] - @           WARNING: CERTIFICATE NAME MISMATCH!           @
[14:49:19:909] [7223:7537] [ERROR][com.freerdp.crypto] - @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
[14:49:19:909] [7223:7537] [ERROR][com.freerdp.crypto] - The hostname used for this connection (xxxxx:3389) 
[14:49:19:909] [7223:7537] [ERROR][com.freerdp.crypto] - does not match the name given in the certificate:
[14:49:19:909] [7223:7537] [ERROR][com.freerdp.crypto] - Common Name (CN):
[14:49:19:909] [7223:7537] [ERROR][com.freerdp.crypto] -    EC2AMAZ-FM25IO2
[14:49:19:909] [7223:7537] [ERROR][com.freerdp.crypto] - A valid certificate for the wrong name should NOT be trusted!
[14:50:38:624] [7223:7537] [ERROR][com.freerdp.crypto] - certificate not trusted, aborting.
[14:50:38:624] [7223:7537] [ERROR][com.freerdp.core] - freerdp_set_last_error ERRCONNECT_CONNECT_CANCELLED [0x0002000B]
[14:50:38:624] [7223:7537] [ERROR][com.freerdp.core.connection] - Error: protocol security negotiation or connection failure
0002000B 00000003

Now this is an internal vpn server so I don’t care at all about certificates. Is there a way to add this certificate to a list that it’s ok? How do I get around this? And as an aside, this was working before the upgrade just fine. I don’t know why it cares now?

asked May 23, 2018 at 18:58

mmaceachran's user avatar

4

I had the same problem on debian sid with latest remmina 1.2.32.1 while connecting to a windows server2008r2 with hardend security settings.

I was able to connect after:

  • updating all freerdp2 libraries (used by remmina) to 2.0.0~git20181120.1 version
  • removing ~/.config/freerdp/known_hosts2 file

The connection security type that worked is «NLA» (negotianion/auto-detection worked too).

Both TLS and RDP didn’t work.

answered Jan 10, 2019 at 20:08

Vasily Galkin's user avatar

2

I’ve found the solution @Ubuntu forums, that forked for me :)

You have to change the Security to «TLS» in the Advanced tab of your connection, and everything works fine!

answered Jul 2, 2018 at 13:15

Vasily's user avatar

3

with RDP connections I get a TLS connection error, you have to look to the correct TLS version:

for me the solution was other way around:

I have to change the Security to «RDP» in the Advanced tab of your connection, and everything works fine!
( I work with debian 10 buster (sid) and remmina 1.2.32)
regards,
from germany

answered Oct 27, 2018 at 13:37

GerdPeter's user avatar

1

I’ve hit the same problem connecting from one of the Ubuntu/Debian family distributive to MS Windows Server 2008 R2.

I managed to solve it this way:

  1. Create new connection with server.name.or.ip:port in Server section (port is optional if u haven’t changed it from standard MS RDP 3389 or/and NATed it through a router if u have one)

  2. In the Advanced tab set
    -«Security protocol negotiation» to «NLA protocol security»
    -«TLS Security level» to «0 — Windows 7 compatible»

Then Remmina only asked me once about accepting the certificate and now it works like a charm.

answered Jul 15, 2022 at 22:07

coldfix's user avatar

Не скучный, прямо дать проблему и решение.

Проблемы

Решение

Modify/etc/xrdp/sesman.iniФайл может быть

  1. открыть файл/etc/xrdp/sesman.ini
sudo vim /etc/xrdp/sesman.ini

sesman.iniСодержимое файла выглядит следующим образом:

[Globals]
ListenAddress=127.0.0.1
ListenPort=3350
EnableUserWindowManager=1
UserWindowManager=startwm.sh
DefaultWindowManager=startwm.sh

[Security]
AllowRootLogin=1
MaxLoginRetry=4
TerminalServerUsers=tsusers
TerminalServerAdmins=tsadmins

[Sessions]
X11DisplayOffset=10
MaxSessions=10
KillDisconnected=0
IdleTimeLimit=0
DisconnectedTimeLimit=0

[Logging]
LogFile=/var/log/xrdp-sesman.log
LogLevel=DEBUG
EnableSyslog=0
SyslogLevel=DEBUG

[X11rdp]
param1=-bs
param2=-ac
param3=-nolisten
param4=tcp

[Xvnc]
param1=-bs
param2=-ac
param3=-nolisten
param4=tcp
param5=-localhost
param6=-dpi
param7=96

  1. в[Xvnc]Добавить нижеparam8=-SecurityTypesс участиемparam9=None
[Xvnc]
param1=-bs
param2=-ac
param3=-nolisten
param4=tcp
param5=-localhost
param6=-dpi
param7=96
param8=-SecurityTypes
param9=None

  1. Перезапустите службу xrdp
sudo service xrdp restart


0

1

Всем привет, нужна помощь.
На компьютере 1 установлена Kubuntu 20.10

Linux 5.8.0-33-generic #36-Ubuntu SMP Wed Dec 9 09:14:40 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Пытаюсь с помощью Remmina 1.4.10 подключиться по rdp к компьютеру 2 на windows 10, пишет, что подключение к серверу потеряно.
Лог отладки:

(remmina_rdp_main) — Not using system proxy settings
(remmina_rdp_tunnel_init) — Tunnel init
(remmina_rdp_tunnel_init) — protocol_plugin_start_direct_tunnel() returned [ххх]:3389
(remmina_rdp_tunnel_init) — Tunnel has been optionally initialized. Now connecting to ххх:3389
(remmina_rdp_main) — proxy_type: (null)
(remmina_rdp_main) — proxy_username: (null)
(remmina_rdp_main) — proxy_password: (null)
(remmina_rdp_main) — proxy_hostname: (null)
(remmina_rdp_main) — proxy_port: 80
(remmina_rdp_main) — Log level set to to INFO
(rmnews_periodic_check) — periodic_rmnews_last_get is 1607757858
(rco_on_disconnect) — Disconnect signal received on RemminaProtocolWidget
(remmina_file_save) — Saving profile
(remmina_file_save) — We have a password and disablepasswordstoring=0
(remmina_file_save) — We have a password and disablepasswordstoring=0
(remmina_file_save) — We have a password and disablepasswordstoring=0
(remmina_file_save) — We have a password and disablepasswordstoring=0
(remmina_file_save) — Profile saved
(rco_on_disconnect) — Could not disconnect

в консоли

Remmina plugin glibsecret (type=Secret) has been registered, but is not yet initialized/activated. The initialization order is 2000.
** (process:10698): CRITICAL **: 18:30:36.304: secret_service_load_collections_sync: assertion ‘paths != NULL’ failed
[glibsecret] unable to get secret service: Unknown error.
Gtk-Message: 18:30:36.415: Failed to load module «colorreload-gtk-module»
StatusNotifier/Appindicator support: your desktop does support it and libappindicator is compiled in Remmina. Good.
Warning: Remmina is running without a secret plugin. Passwords will be saved in a less secure way.
(org.remmina.Remmina:10698): Gtk-WARNING **: 18:30:36.487: gtk_menu_attach_to_widget(): menu already attached to GtkMenuItem
Remmina is compiled as a SNAP package.
but we can’t find the secret plugin inside the SNAP.
[18:30:41:843] [10698:10780] [INFO][com.freerdp.core] — freerdp_connect:freerdp_set_last_error_ex resetting error state
[18:30:41:844] [10698:10780] [INFO][com.freerdp.client.common.cmdline] — loading channelEx rdpdr
[18:30:41:844] [10698:10780] [INFO][com.freerdp.client.common.cmdline] — loading channelEx rdpsnd
[18:30:41:844] [10698:10780] [INFO][com.freerdp.client.common.cmdline] — loading channelEx drdynvc
[18:30:42:191] [10698:10780] [INFO][com.freerdp.primitives] — primitives autodetect, using optimized
[18:30:42:202] [10698:10780] [INFO][com.freerdp.core.nego] — Detecting if host can be reached locally. — This might take some time.
[18:30:42:202] [10698:10780] [INFO][com.freerdp.core.nego] — To disable auto detection use /gateway-usage-method:direct
[18:30:42:243] [10698:10780] [INFO][com.freerdp.core] — freerdp_tcp_connect:freerdp_set_last_error_ex resetting error state
[18:30:43:245] [10698:10780] [ERROR][com.freerdp.core] — freerdp_tcp_connect:freerdp_set_last_error_ex ERRCONNECT_CONNECT_FAILED [0x00020006]
[18:30:43:245] [10698:10780] [ERROR][com.freerdp.core] — failed to connect to ххх
[18:30:43:326] [10698:10780] [INFO][com.freerdp.core] — freerdp_tcp_connect:freerdp_set_last_error_ex resetting error state
[18:31:35:194] [10698:10780] [ERROR][com.freerdp.core] — rdg_establish_data_connection:freerdp_set_last_error_ex ERRCONNECT_ACCESS_DENIED [0x00020016]
libfreerdp returned code is 00020016

ПС. С компьютера на котором установлена windows подключается нормально.


До прошлой ночи у меня была Реммина, работающая нормально. Я мог запустить RDP через туннель SSH, и все было хорошо.

Тогда это перестало работать. Я могу добраться до диалогового окна с паролем для моей рабочей машины, но тогда это просто говорит Cannot connect to RDP server localhost.

Я даже не могу найти журналы, которые выглядят интересно. Я переустановил remmina, очистил свой .remminaкаталог, перезапустил мою машину и даже перезапустил мой шлюз.

Просто чтобы сделать это действительно странным, мой ноутбук (который имеет ту же настройку — последние версии Ubuntu и Remmina) может установить соединение просто отлично. Он даже проходит через тот же маршрутизатор, хотя и по беспроводной сети.

Есть предположения?


Ответы:


Я понятия не имею, почему это работает, но я начал менять настройки по одному. Когда я отредактировал свойства соединения, я посмотрел на вкладку «Дополнительно» и изменил безопасность с «согласовать» на «TLS», и вуаля, все работает.

Как ни странно, «вести переговоры» по-прежнему работает на ноутбуке, но, по крайней мере, я вернулся к бизнесу с моим большим монитором :)





Это случилось со мной, и я нашел ответ, который решил проблему. Просто rm ~/.freerdp/known_hostsи попробуйте еще раз.

Очевидно, это происходит, когда меняются ключи на туннельном сервере. Смотрите эту ошибку .

ОБНОВИТЬ

Первая ссылка теперь указывает на удаленный ответ, поэтому вот дополнительная информация по этой ссылке:

  • Кажется, что файл «known_hosts» содержит некоторые данные маршрутизации для каждого сервера, эти данные иногда устаревают, а когда Remmina пытается подключиться с использованием устаревших данных, происходит сбой. Удаление файла known_hosts решает эту проблему. — Эрель Сегал-Халеви 13 декабря 12:06

  • FWIW, моя проблема не имела никакого отношения к known_hosts (как объяснено ниже), но все, что связано с настройками безопасности: см.
    Http://www.bauer-power.net/2013/10/unable-to-connect-to-rdp -server-in.html
    для деталей. — Томислав Накич-Альфиревич 24 апреля ’14 в 10:58

  • Полностью сработало, мне было интересно, где хранятся сертификаты. У меня была та же проблема по большей части: я использовал Remmina для RDP на определенную машину, затем однажды он перестал работать (ничего на удаленной машине не изменилось). Другие RDP-соединения, которые я сохранил, все еще работали, за исключением этой машины. Это случилось с использованием аутентификации NLA, которая, кажется, является частью проблемы с новейшей Remmina, не сохраняющей сертификаты. — Николи 26 апреля ’13 в 20:26

  • спасибо, раньше он отлично соединялся, затем я переформатировал сервер, и он перестал работать, удалив строку для этого хоста. — Bor691 15 января 14 года в 8:50

  • Мне нужно использовать две службы на одном и том же адресе, но на разных портах, и повторное использование — единственный способ подключиться к обоим. — Гринго Суаве 13 октября 14:55






Это случилось со мной, когда я скопировал свою конфигурацию remmina (под ~/.remmina) с одной машины на другую. Возможно версии remmina были другими; изменение безопасности не помогло, но удаление и воссоздание соединения сделали.


Это сработало для меня, изменив безопасность на NLA по неизвестной причине.





Проблема в настройке viewmode = 1 в сохраненном файле conf. Если вы измените размер окна, оно должно обновиться и начать показывать сеанс. Изменение этого логического значения на 0 заставит окно по умолчанию и оно будет обновляться при загрузке. Проблема в том, что если вы измените размер окна после начала сеанса, remmina вернет этот параметр обратно.

A work around would be to set the window_maximize=0 to true and then just click/press the maximize button/shortcut to bring it back to your settings. 
window_maximize=1 
window_height=960 
viewmode=1 
Window_width=1440

Вероятно, глупый ответ, но проблема для меня заключалась в том, что я пытался подключиться через открытую сеть Wi-Fi (незашифрованную), и remmina этого не допустила. Как только я подключился к безопасной сети, все снова заработало, как и планировалось.



Это также может быть проблема с проверкой сертификата. Чтобы проверить, является ли это проблемой, перейдите по ссылке:

Дополнительно -> проверить «Игнорировать сертификат»

Будьте осторожны, если эта проверка отключена, вы можете быть открытыми для человека в середине атаки. Но должно быть нормально подключаться по внутренним сетям.

  • Печать

Страницы: 1 [2] 3  Все   Вниз

Тема: remmina ошибка «Невозможно подключиться к серверу RDP» при подключении к windows  (Прочитано 54244 раз)

0 Пользователей и 1 Гость просматривают эту тему.

Оффлайн
Leo_87

1) грохнуть ~/.freerdp
2) проверить под другим пользователем

Грохнул.
Под другим пользователем заходит, а как под тем который нужен зайти?


Оффлайн
ArcFi

Leo_87, удаление ~/.freerdp помогло?


Оффлайн
Leo_87

Leo_87, удаление ~/.freerdp помогло?

Помогло на одной машине.
На других удалил, под другим пользователем пускает. Но под тем который нужен не хочет.
Что ещё можно посмотреть?


Оффлайн
ArcFi

Leo_87, там, где не работает, показывайте:

cat /etc/issue
nmap -Pn -sV -p PORT IP
PORT — RDP-порт, обычно 3389
IP — адрес RDP-сервера


Оффлайн
Leo_87

Leo_87, там, где не работает, показывайте:

Starting Nmap 5.21 ( http://nmap.org ) at 2013-07-18 11:13 MSK
Nmap scan report for 192.168.0.9
Host is up (0.00066s latency).
PORT     STATE SERVICE       VERSION
3389/tcp open  ms-term-serv?

Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 99.19 seconds


Оффлайн
Leo_87

Проблему решил.
Помимо папки ~/.freerdp , нужно удалить все файлы из папки ~/.remmina
Спасибо за помощь.


Оффлайн
ArcFi

В ~/.remmina лежит конфиг и настройки всех подключений, с этим надо аккуратнее, а то можно наудалять лишнего.


Оффлайн
sergicus

у меня была похожая проблема.
Решил — помогло — в настройках профиля подключения -> дополнительные -> безопасность , в этом пункте установить вместо автосогласования RDP


Оффлайн
Ods

у меня была похожая проблема.
Решил — помогло — в настройках профиля подключения -> дополнительные -> безопасность , в этом пункте установить вместо автосогласования RDP

Огромная благодарность автору поста! Несколько дней была лишена доступа к работе, куча нервов и времени, нигде и ничего толкового, все удаляла, чистила, грузила заново — эффекта 0 и только ваша подсказка за секунду решила все проблемы!!! Спасибо форуму и автору sergicus!


Оффлайн
vadimvolodin

как то давно ремина начала глючить, не когда было разбираться поставил KRDC и забыл про ремину.


Оффлайн
Storke

у меня была похожая проблема.
Решил — помогло — в настройках профиля подключения -> дополнительные -> безопасность , в этом пункте установить вместо автосогласования RDP

Благодарю за помощь! Тоже мучился полдня. Remmina без проблем подключалась из Ubuntu 14.04 к Windows Server 2008 R2 в роли сервера терминалов. Как только создал домен, убрав сервер терминалов, возникла та же байда. После выбора вместо Согласование RDP снова смог подключиться.


Оффлайн
serp53

Всё опробовал что указано выше в топике и не помогло.
Предыстория. У меня раньше терминальный сервер (Windows server 2008 R2) был не в домене и всё работало, по производственной необходимости пришлось терминальный сервер подключить к домену. После подключения «Remmina» отказалась подключаться к терминальному серверу (Windows server 2008 R2).
В моём случае, после того как поставил галочку «Прикрепить к консоли (windows 2003 / 2003 R2)» «Remmina» стала подключаться.


Оффлайн
kac

Кстати очень много проблем решает remmina ppa. Каждую неделю есть обновления.много проблем решилось.


Оффлайн
jenkidu

Была точно такая же проблема. На сервер с винды по RDP зайти могу, с Ubuntu 14.04 не могу (невозможно подключиться к серверу RDP).
Удаление папки .freerdp помогло.
Заново выдался сертификат, все заработало.


Оффлайн
guertauli

Заново выдался сертификат, все заработало.

Что-бы сертификат не прописывался никогда:
1. Удалить все содержимое внутри папки .freerdp
2. chmod u-w .freerdp

« Последнее редактирование: 08 Марта 2016, 18:59:34 от guertauli »


  • Печать

Страницы: 1 [2] 3  Все   Вверх

Уже не однократно пришлось столкнуться с проблемой подключения Remmina по RDP к серверам Windows. Попытки установить соединение приводят к ошибке «Невозможно подключиться к серверу RDP».

Не секрет, что для работы по протоколу RDP Remmina использует freerdp, и все хосты с которыми хоть раз устанавливалось соединение добавляются в файл ~/.freerdp/known_hosts, аналогично ssh, собственно получаем и проблему типичную для ssh. При смене сертификата или ключа нам требуется удалить старую запись о сервере.

Если у вас не 100500 серверов, то можно просто удалить каталог ~/.freerdp

rm -r ~/.freerdp

Бывает помимо каталога ~/.freerdp, требуется также удалить все файлы из каталога ~/.remmina

Подписывайтесь на канал

Яндекс.Дзен

и узнавайте первыми о новых материалах, опубликованных на сайте.

25 мая, 2017 11:40 дп
93 893 views
| Комментариев нет

Linux, SSH

В первой статье этой серии вы узнали о том, как и в каких ситуациях вы можете попробовать исправить ошибки SSH. Остальные статьи расскажут, как определить и устранить ошибки:

  • Ошибки протокола: в этой статье вы узнаете, что делать, если сбрасываются клиентские соединения, клиент жалуется на шифрование или возникают проблемы с неизвестным или измененным удаленным хостом.
  • Ошибки аутентификации: поможет устранить проблемы с парольной аутентификацией или сбросом SSH-ключей.
  • Ошибки оболочки: это руководство поможет исправить ошибки ветвления процессов, валидации оболочки и доступа к домашнему каталогу.

Для взаимодействия SSH-клиента с SSH-сервером необходимо установить базовое сетевое подключение. Это руководство поможет определить некоторые общие ошибки подключения, исправить их и предотвратить их возникновение в будущем.

Требования

  • Убедитесь, что можете подключиться к виртуальному серверу через консоль.
  • Проверьте панель на предмет текущих проблем, влияющих на работу и состояние сервера и гипервизора.

Основные ошибки

Разрешение имени хоста

Большинство ошибок подключения возникает тогда, когда ссылка на хост SSH не может быть сопоставлена с сетевым адресом. Это почти всегда связано с DNS, но первопричина часто бывает не связана с DNS.

На клиенте OpenSSH эта команда:

ssh user@example.com

может выдать ошибку:

ssh: Could not resolve hostname example.com: Name or service not known

В PuTTY может появиться такая ошибка:

Unable to open connection to example.com Host does not exist

Чтобы устранить эту ошибку, можно попробовать следующее:

  • Проверьте правильность написания имени хоста.
  • Убедитесь, что вы можете разрешить имя хоста на клиентской машине с помощью команды ping. Обратитесь к сторонним сайтам (WhatsMyDns.net, например), чтобы подтвердить результаты.

Если у вас возникают проблемы с разрешением DNS на любом уровне, в качестве промежуточного решения можно использовать IP-адрес сервера, например:

ssh user@111.111.111.111
# вместо
ssh user@example.com.

Истечение времени соединения

Эта ошибка значит, что клиент попытался установить соединение с SSH-сервером, но сервер не смог ответить в течение заданного периода ожидания.

На клиенте OpenSSH следующая команда:

ssh user@111.111.111.111

выдаст такую ошибку:

ssh: connect to host 111.111.111.111 port 22: Connection timed out

В PuTTY ошибка выглядит так:

Network error: Connection timed out

Чтобы исправить ошибку:

  • Убедитесь, что IP-адрес хоста указан правильно.
  • Убедитесь, что сеть поддерживает подключение через используемый порт SSH. Некоторые публичные сети могут блокировать порт 22 или пользовательские SSH-порты. Чтобы проверить работу порта, можно, например, попробовать подключиться к другим хостам через этот же порт. Это поможет вам определить, не связана ли проблема с самим сервером.
  • Проверьте правила брандмауэра. Убедитесь, что политика по умолчанию – не DROP.

Отказ в соединении

Эта ошибка означает, что запрос передается на хост SSH, но хост не может успешно принять запрос.

На клиенте OpenSSH следующая команда выдаст ошибку:

ssh user@111.111.111.111
ssh: connect to host 111.111.111.111 port 22: Connection refused

В PuTTY ошибка появится в диалоговом окне:

Network error: Connection refused

Эта ошибка имеет общие с ошибкой Connection Timeout причины. Чтобы исправить её, можно сделать следующее:

  • Убедиться, что IP-адрес хоста указан правильно.
  • Убедиться, что сеть поддерживает подключение через используемый порт SSH. Некоторые публичные сети могут блокировать порт 22 или пользовательские SSH-порты. Чтобы проверить работу порта, можно, например, попробовать подключиться к другим хостам через этот же порт.
  • Проверить правила брандмауэра. Убедитесь, что политика по умолчанию – не DROP, и что брандмауэр не блокирует этот порт.
  • Убедиться, что сервис запущен и привязан к требуемому порту.

Рекомендации по исправлению ошибок подключения

Брандмауэр

Иногда проблемы с подключением возникают из-за брандмауэра. Он может блокировать отдельные порты или сервисы.

Читайте также: Что такое брандмауэр и как он работает?

В разных дистрибутивах используются разные брандмауэры. Вы должны научиться изменять правила и политики своего брандмауэра. В Ubuntu обычно используется UFW, в CentOS – FirewallD. Брандмауэр iptables используется независимо от системы.

Читайте также:

  • Основы UFW: общие правила и команды фаервола
  • Настройка брандмауэра FirewallD в CentOS 7
  • Основы Iptables: общие правила и команды брандмауэра

Чтобы настроить брандмауэр, нужно знать порт сервиса SSH. По умолчанию это порт 22.

Чтобы запросить список правил iptables, введите:

iptables -nL

Такой вывод сообщает, что правил, блокирующих SSH, нет:

Chain INPUT (policy ACCEPT)
target     prot opt source               destination
Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Если в выводе вы видите правило или политику по умолчанию REJECT или DROP, убедитесь, что цепочка INPUT разрешает доступ к порту SSH.

Чтобы запросить список правил FirewallD, введите:

firewall-cmd --list-services

Список, появившийся на экране, содержит все сервисы, которые поддерживаются брандмауэром. В списке должно быть правило:

dhcpv6-client http ssh

Если вы настроили пользовательский порт SSH, используйте опцию –list-ports. Если вы создали пользовательское определение сервиса, добавьте опцию –list-services, чтобы найти SSH.

Чтобы проверить состояние UFW, введите:

ufw status

Команда вернёт доступные порты:

Status: active
To                         Action      From
--                         ------      ----
22                         LIMIT       Anywhere
443                        ALLOW       Anywhere
80                         ALLOW       Anywhere
Anywhere                   ALLOW       192.168.0.0
22 (v6)                    LIMIT       Anywhere (v6)
443 (v6)                   ALLOW       Anywhere (v6)
80 (v6)                    ALLOW       Anywhere (v6)

В списке должен быть порт SSH.

Проверка состояния сервиса SSH

Если вы не можете подключиться к серверу по SSH, убедитесь, что сервис SSH запущен. Способ сделать это зависит от операционной системы сервера. В более старых версиях дистрибутивов (Ubuntu 14.04, CentOS 6, Debian 8) используется команда service. Современные дистрибутивы на основе Systemd используют команду systemctl.

Метод проверки состояния сервиса может варьироваться от системы к системе. В более старых версиях (Ubuntu 14 и ниже, CentOS 6, Debian 6) используется команда service, поддерживаемая системой инициализации Upstart, а в более современных дистрибутивах для управления сервисом используется команда systemctl.

Примечание: В дистрибутивах Red Hat (CentOS и Fedora) сервис называется sshd, а в Debian и Ubuntu – ssh.

В более старых версия используйте команду:

service ssh status

Если процесс работает должным образом, вы увидите вывод, который содержит PID:

ssh start/running, process 1262

Если сервис не работает, вы увидите:

ssh stop/waiting

В системах на основе SystemD используйте:

systemctl status sshd

В выводе должна быть строка active:

sshd.service - OpenSSH server daemon
Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled)
Active: active (running) since Mon 2017-03-20 11:00:22 EDT; 1 months 1 days ago
Process: 899 ExecStartPre=/usr/sbin/sshd-keygen (code=exited, status=0/SUCCESS)
Main PID: 906 (sshd)
CGroup: /system.slice/sshd.service
├─  906 /usr/sbin/sshd -D
├─26941 sshd: [accepted]
└─26942 sshd: [net]

Если сервис не работает, вы увидите в выводе inactive:

sshd.service - OpenSSH server daemon
Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled)
Active: inactive (dead) since Fri 2017-04-21 08:36:13 EDT; 2s ago
Process: 906 ExecStart=/usr/sbin/sshd -D $OPTIONS (code=exited, status=0/SUCCESS)
Process: 899 ExecStartPre=/usr/sbin/sshd-keygen (code=exited, status=0/SUCCESS)
Main PID: 906 (code=exited, status=0/SUCCESS)

Чтобы перезапустить сервис, введите соответственно:

service ssh start
systemctl start sshd

Проверка порта SSH

Существует два основных способа проверить порт SSH: проверить конфигурационный файл SSH или просмотреть запущенный процесс.

Как правило, конфигурационный файл SSH хранится в /etc/ssh/sshd_config. Стандартный порт 22 может переопределяться любой строкой в этом файле, определяющей директиву Port.

Запустите поиск по файлу с помощью команды:

grep Port /etc/ssh/sshd_config

Читайте также: Использование Grep и регулярных выражений для поиска текстовых шаблонов в Linux

Команда вернёт:

Port 22

Если вы уже убедились, что сервис работает, теперь вы можете узнать, работает ли он на требуемом порте. Для этого используйте команду ss. Команда netstat –plnt выдаст аналогичный результат, но команду ss рекомендуется использовать для запроса информации сокета из ядра.

ss -plnt

В выводе должно быть указано имя программы и порт, который она прослушивает. Например, следующий вывод сообщает, что сервис SSH прослушивает все интерфейсы и порт 22.

State       Recv-Q Send-Q              Local Address:Port                       Peer Address:Port
LISTEN      0      128                 *:22                                     *:*                   users:(("sshd",pid=1493,fd=3))
LISTEN      0      128                 :::22                                    :::*                  users:(("sshd",pid=1493,fd=4))

Символ * и 0.0.0.0 указывает, что все интерфейсы сервера прослушиваются. Строка 127.0.0.1 значит, что сервис не является общедоступным. В sshd_config директива ListenAddress должна быть закомментирована, чтобы прослушивать все интерфейсы, или должна содержать внешний IP-адрес сервера.

Если у вас не получается самостоятельно настроить соединение SSH, вы можете обратиться за помощью к службе поддержки своего хостинг-провайдера.

Tags: firewalld, Iptables, OpenSSH, PuTTY, SSH, UFW

Как правильно задавать вопросы

Правильно сформулированный вопрос и его грамотное оформление способствует высокой вероятности получения достаточно содержательного и по существу ответа. Общая рекомендация по составлению тем: 1. Для начала воспользуйтесь поиском форума. 2. Укажите версию ОС вместе с разрядностью. Пример: LM 19.3 x64, LM Sarah x32 3. DE. Если вопрос касается двух, то через запятую. (xfce, KDE, cinnamon, mate) 4. Какое железо. (достаточно вывод inxi -Fxz в спойлере (как пользоваться спойлером смотрим здесь)) или же дать ссылку на hw-probe 5. Суть. Желательно с выводом консоли, логами. 6. Скрин. Просьба указывать 2, 3 и 4 независимо от того, имеет ли это отношение к вопросу или нет. Так же не забываем об общих правилах Как пример вот

no avatar

Sulfur

Сообщения: 92
Зарегистрирован: 07 окт 2019, 10:44
Решено: 3
Благодарил (а): 12 раз
Контактная информация:

Перестала работать Remmina

16 апр 2021, 13:05

Всем привет. Имеется Mint 19.3 и remmina 1.4.11. Сегодня внезапно перестал работать rdp до терминальника (windows server 2012), да и вообще до всех ПК определенной организации. «Невозможно подключиться к RDP серверу». Примечательно, что с винды rdp работает и подключения rdp в remmina к пк другой организации тоже прекрасно работает. Пробовал удалить файл known_hosts2 в .config/freerdp, но не помогло. Уже была такая проблема, переустанавливал заново remmina, и отпустило. Сейчас опять, хотелось бы понять причину.

Решение Sulfur » 21 апр 2021, 18:35


Может кому пригодится — изменил в сетевом подключении MTU на 576 и всё стало работать.


Перейти к ответу ➙


Аватара пользователя

slant

Сообщения: 4230
Зарегистрирован: 21 июн 2017, 18:09
Решено: 82
Благодарил (а): 51 раз
Поблагодарили: 1825 раз
Контактная информация:

Перестала работать Remmina

#2

16 апр 2021, 13:19

Для начала стоит выяснить — это сам RDP не может подключится, или сеть в системе частично отвалилась. Маршрут, фаервол, что-нить еще…


no avatar

Sulfur

Сообщения: 92
Зарегистрирован: 07 окт 2019, 10:44
Решено: 3
Благодарил (а): 12 раз
Контактная информация:

Перестала работать Remmina

#3

16 апр 2021, 13:34

Попробовал через xfreerdp

xfreerdp /u:****** /p:****** /v:10.88.****.***
[13:29:30:954] [16667:16668] [INFO][com.freerdp.core] — freerdp_connect:freerdp_set_last_error_ex resetting error state
[13:29:30:954] [16667:16668] [INFO][com.freerdp.client.common.cmdline] — loading channelEx rdpdr
[13:29:30:954] [16667:16668] [INFO][com.freerdp.client.common.cmdline] — loading channelEx rdpsnd
[13:29:30:954] [16667:16668] [INFO][com.freerdp.client.common.cmdline] — loading channelEx cliprdr
[13:29:31:288] [16667:16668] [INFO][com.freerdp.primitives] — primitives autodetect, using optimized
[13:29:31:292] [16667:16668] [INFO][com.freerdp.core] — freerdp_tcp_is_hostname_resolvable:freerdp_set_last_error_ex resetting error state
[13:29:31:292] [16667:16668] [INFO][com.freerdp.core] — freerdp_tcp_connect:freerdp_set_last_error_ex resetting error state
[13:29:31:534] [16667:16668] [WARN][com.freerdp.crypto] — Certificate verification failure ‘unable to get local issuer certificate (20)’ at stack position 0
[13:29:31:534] [16667:16668] [WARN][com.freerdp.crypto] — CN = ***.****.****
[13:29:32:537] [16667:16668] [ERROR][com.winpr.timezone] — Unable to get current timezone rule
[13:29:40:544] [16667:16668] [ERROR][com.freerdp.core.connection] — Timeout waiting for activation


Аватара пользователя

rogoznik

Сообщения: 9657
Зарегистрирован: 27 июн 2017, 13:36
Решено: 120
Откуда: Нижний Тагил
Благодарил (а): 755 раз
Поблагодарили: 1849 раз
Контактная информация:

Перестала работать Remmina

#4

16 апр 2021, 14:07

Sulfur писал(а): ↑

16 апр 2021, 13:34


[13:29:32:537] [16667:16668] [ERROR][com.winpr.timezone] — Unable to get current timezone rule

Собственно

Изображение

Изображение


no avatar

Sulfur

Сообщения: 92
Зарегистрирован: 07 окт 2019, 10:44
Решено: 3
Благодарил (а): 12 раз
Контактная информация:

Перестала работать Remmina

#5

16 апр 2021, 14:17

Гуглил этот момент, но так и не понял что с этим делать

[13:29:32:537] [16667:16668] [ERROR][com.winpr.timezone] — Unable to get current timezone rule

Часовой пояс у меня выставлен, время корректное отображает


Аватара пользователя

Chocobo

Сообщения: 10009
Зарегистрирован: 27 авг 2016, 22:57
Решено: 215
Откуда: НН
Благодарил (а): 812 раз
Поблагодарили: 2998 раз
Контактная информация:

Перестала работать Remmina

#6

16 апр 2021, 14:18

Sulfur, xfreerdp к тем хостам, куда справляется и реммина покажет другие ошибки/ворнинги?

Изображение

   

Изображение


no avatar

Sulfur

Сообщения: 92
Зарегистрирован: 07 окт 2019, 10:44
Решено: 3
Благодарил (а): 12 раз
Контактная информация:

Перестала работать Remmina

#7

16 апр 2021, 14:22

Chocobo писал(а): ↑

16 апр 2021, 14:18


Sulfur, xfreerdp к тем хостам, куда справляется и реммина покажет другие ошибки/ворнинги?

К хостам другой организации, к которым remmina подключается, xfreerdp работает тоже, но данную ошибку «Unable to get current timezone rule» тоже показывает.


no avatar

Sulfur

Сообщения: 92
Зарегистрирован: 07 окт 2019, 10:44
Решено: 3
Благодарил (а): 12 раз
Контактная информация:

Перестала работать Remmina

#8

16 апр 2021, 14:34

Собственно при подключении к одним хостам (одной организации) после появление этой ошибки

[13:29:32:537] [16667:16668] [ERROR][com.winpr.timezone] — Unable to get current timezone rule

rdp работает, а при подключении к другим хостам (другой организации) rdp не запускается. А так, по ходу подключения, ошибки/варнинги идентичные идут.


Аватара пользователя

Chocobo

Сообщения: 10009
Зарегистрирован: 27 авг 2016, 22:57
Решено: 215
Откуда: НН
Благодарил (а): 812 раз
Поблагодарили: 2998 раз
Контактная информация:

Перестала работать Remmina

#9

16 апр 2021, 14:44

Sulfur писал(а): ↑

16 апр 2021, 13:34


[13:29:31:534] [16667:16668] [WARN][com.freerdp.crypto] — Certificate verification failure ‘unable to get local issuer certificate (20)’ at stack position 0

Меня больше вот эта смущала, может таймауты вызваны тем, что хендшейк предварительно уже обломался

Изображение

   

Изображение


no avatar

Sulfur

Сообщения: 92
Зарегистрирован: 07 окт 2019, 10:44
Решено: 3
Благодарил (а): 12 раз
Контактная информация:

Перестала работать Remmina

#10

16 апр 2021, 14:46

Chocobo писал(а): ↑

16 апр 2021, 14:44


Меня больше вот эта смущала, может таймауты вызваны тем, что хендшейк предварительно уже обломался

Не, эта же ошибка появляется даже тогда, когда rdp в итоге работает. Проверил, сверил…


no avatar

Sulfur

Сообщения: 92
Зарегистрирован: 07 окт 2019, 10:44
Решено: 3
Благодарил (а): 12 раз
Контактная информация:

Перестала работать Remmina

#11

21 апр 2021, 18:35

Может кому пригодится — изменил в сетевом подключении MTU на 576 и всё стало работать.


Аватара пользователя

ilikethat

Сообщения: 481
Зарегистрирован: 14 дек 2019, 01:46
Решено: 9
Благодарил (а): 111 раз
Поблагодарили: 106 раз
Контактная информация:

Перестала работать Remmina

#12

21 апр 2021, 23:20

Или Вы или организация перешли на мобильный интернет.
Возможно это резервный канал.
Хотя странно, RDP поверх TCP работает, на размер пакетов ему должно быть пофиг. Возможно канал гавеный и/или перегружен так, что попытки собрать пакет из пары-тройки кусков приводят к потери связи.


Аватара пользователя

slant

Сообщения: 4230
Зарегистрирован: 21 июн 2017, 18:09
Решено: 82
Благодарил (а): 51 раз
Поблагодарили: 1825 раз
Контактная информация:

Перестала работать Remmina

#13

22 апр 2021, 00:05

ilikethat писал(а): ↑

21 апр 2021, 23:20


Хотя странно, RDP поверх TCP работает, на размер пакетов ему должно быть пофиг.

Не совсем в этом дело. Тут MTU/MSS blackhole по всей видимости приключился. Несогласованность максимального размера пакета. Часто случается если соединение включает в себя pppoe или pptp, либо действительно мобильную связь.
Кстати, имеет смысл попробовать нащупать верхний предел MTU при котором оно нормально работает. Т.к. настолько урезанный MTU зажимает пропускную способность канала.


no avatar

Sulfur

Сообщения: 92
Зарегистрирован: 07 окт 2019, 10:44
Решено: 3
Благодарил (а): 12 раз
Контактная информация:

Перестала работать Remmina

#14

22 апр 2021, 00:22

Не понятен момент, почему на моем же компе с виртуальной машиной на windows 7 такие проблемы с rdp не наблюдаются


Аватара пользователя

ilikethat

Сообщения: 481
Зарегистрирован: 14 дек 2019, 01:46
Решено: 9
Благодарил (а): 111 раз
Поблагодарили: 106 раз
Контактная информация:

Перестала работать Remmina

#15

22 апр 2021, 09:42

Sulfur, так вот же slant предположил, что некорректно срабатывает алгоритм динамического определения MTU в Linux. В Windows, в 7ке точно, такого нет. А виртуалка пуляет пакеты в сеть на низком уровне, минуя стадию определения MTU.


no avatar

Sulfur

Сообщения: 92
Зарегистрирован: 07 окт 2019, 10:44
Решено: 3
Благодарил (а): 12 раз
Контактная информация:

Перестала работать Remmina

#16

22 апр 2021, 09:53

ilikethat писал(а): ↑

22 апр 2021, 09:42


так вот же slant предположил, что некорректно срабатывает алгоритм динамического определения MTU в Linux.

Мне показалось что речь шла о том, что нет ICMP сообщения о необходимости фрагментации, а не о конкретно проблеме в Linux.


Аватара пользователя

ilikethat

Сообщения: 481
Зарегистрирован: 14 дек 2019, 01:46
Решено: 9
Благодарил (а): 111 раз
Поблагодарили: 106 раз
Контактная информация:

Перестала работать Remmina

#17

22 апр 2021, 10:11

Sulfur, алгоритм Path MTU Discovery, определения динамически MTU, работает через ICMP пакеты.
Шлет пакеты разного размера с флагом «не дефрагментировать» — не разбивать пакет на части.
Какие максимально пакеты пройдут — такой MTU и установится, для конкретного IP к которому Вы коннектитесь.
Так вот, на каком-то роутере в инете такие пакеты могут убиваться правилами админа, либо идти по другому маршруту, либо еще чего…
В результате MTU определяется неправильно. Связи нет.
В винде такого алгоритма просто нет.


  • Ошибка подключения к серверу вайбер на телефоне что делать
  • Ошибка подключения к серверам rainbow six siege 3 0x00030089
  • Ошибка подключения к серверу базы данных
  • Ошибка подключения к серверам rainbow six siege 3 0x0001000b
  • Ошибка подключения к серверу авторизации тарков