Remmina ошибка при запуске сеанса ssh

  • Печать

Страницы: [1]   Вниз

Тема: Обход ошибки Remmina при соединении по SSH по ключам  (Прочитано 2350 раз)

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

Оффлайн
andy_minsk

В Remmina, на протяжении долгого времени сохраняется странный баг при соединении по ключам, который проявляется в невозможности соединения из-за отсутствия или несовпадения ключа, хотя в терминале и других клиентах все проходит нормально.
Случайно наскочил на обход данного бага, который решил проблему. Собственно описание по ссылке http://ru-root.livejournal.com/2371615.html
Достаточно было только ввести

ssh-add ~/.ssh/*.rsa (или вместо маски имя вашего ключа(ключей)), чтобы авторизация по публичному ключу начала работать правильно. Надеюсь поможет кому-то :)


Оффлайн
ArcFi

Если что, в гноме gnome-keyring это должен делать автоматом.


Оффлайн
andy_minsk

unity  :). В нем, похоже, автоматом не проходит. Во всяком случае, не на всех ssh соединениях Remmina работает по умолчанию.


Оффлайн
ArcFi

У меня примерно дюжина подключений, 4 ключа.
С указанной проблемой не сталкивался.
У вас seahorse все ключи видит?



Оффлайн
ArcFi

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

Даже без явного указания способа аутентификации / файла ключа на клиенте, так?

Просто remmina используется для многого другого и неохота зоопарк держать на машине.

Знакомая история.
Правда, у меня такая беда, что при завершении сеанса ssh (в частности, при удалённой перезагрузке), remmina частенько виснет, причём со всеми открытыми вкладками.
Поэтому для ssh приходится юзать терминал.


  • Печать

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

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

Правильно сформулированный вопрос и его грамотное оформление способствует высокой вероятности получения достаточно содержательного и по существу ответа. Общая рекомендация по составлению тем: 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

machulan

Сообщения: 60
Зарегистрирован: 18 ноя 2016, 14:24
Благодарил (а): 4 раза
Поблагодарили: 10 раз
Контактная информация:

Удаленный доступ

18 ноя 2016, 15:55

Установил Linux Mint 18 Mate 32. Удаленный доступ по rdesktop работает нормально, но в терминале остается запись об ошибке. Команда в терминале следующая — rdesktop -f -k common -a16 -u логин -p пароль 123.456.789:3333 (в Linux Mint 17.2 работало совершенно корректно).
Vinagre — работает, за исключением глюка — при включенной цифровой клавиатуре курсорные клавиши печатают цифры. Для их нормальной работы надо отключить цифровую клавиатуру.
Установил Linux Mint 18 Cinnamon 32. rdesktop работает некорректно — невозможно использовать панель задач на удаленном рабочем столе — мышка «пробивает» на локальный компьютер, срабатывают действия по нажатию значков на локальном компьютере. Vinagre — те же глюки, что и на Cinnamon, плюс наоборот действует индикатор цифровой клавиатуры.


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

Chocobo

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

Re: Удаленный доступ

#2

18 ноя 2016, 16:16

machulan писал(а): но в терминале остается запись об ошибке.

Её стоило бы указать.

Встречный вопрос, к каким осям цепляемся?
и почему, если rdp то не remmina ? :smile:

Изображение

   

Изображение


no avatar

machulan

Сообщения: 60
Зарегистрирован: 18 ноя 2016, 14:24
Благодарил (а): 4 раза
Поблагодарили: 10 раз
Контактная информация:

Re: Удаленный доступ

#3

18 ноя 2016, 16:47

ERROR: CredSSP: Initialize failed, do you have correct kerberos tgt initialized ?
Подключаюсь к Windows 7 Pro 64. До remmina не дошел, пробовал использовать FreeRDP — установил, но не смог использовать, так как программа не появилась в меню (В диспетчере программ — «установлено»)


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

Chocobo

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

Re: Удаленный доступ

#4

18 ноя 2016, 16:50

machulan писал(а): До remmina не дошел,

Самый беспроблемный клиент, по опыту)

Ошибка с керберосом — это что-то на тему доменной связности.

Изображение

   

Изображение


no avatar

machulan

Сообщения: 60
Зарегистрирован: 18 ноя 2016, 14:24
Благодарил (а): 4 раза
Поблагодарили: 10 раз
Контактная информация:

Re: Удаленный доступ

#5

18 ноя 2016, 17:25

Вспоминаю, что в прошлый подход к линуксу минт 17,2 я использовал ремину. Сейчас запустил, но что-то не учел в настройках. Помню, в прошлый раз что-то касалось SSH… Сейчас на первом экране — RDP, в «параметры удаленного рабочего стола» — протокол SSH, сервер — …, Кодировка — ASCII (?), имя пользователя, пароль. В «правка/параметры» ничего не менял, кроме «Локальный порт SSH-туннеля» — махнул случайно и не помню, что было по умолчанию. При попытке подключения показывает «Ошибка при запуске сеанса SSH: Timeout…» Не подскажете с настройками ?


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

Chocobo

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

Re: Удаленный доступ

#6

18 ноя 2016, 17:53

machulan писал(а): Ошибка при запуске сеанса SSH: Timeout..

протокол должен быть доступен rdp, доставь пакетик remmina-plugin-rdp

remmina.png

Изображение

   

Изображение


no avatar

machulan

Сообщения: 60
Зарегистрирован: 18 ноя 2016, 14:24
Благодарил (а): 4 раза
Поблагодарили: 10 раз
Контактная информация:

Re: Удаленный доступ

#7

18 ноя 2016, 17:54

ок, сейчас попробую


no avatar

machulan

Сообщения: 60
Зарегистрирован: 18 ноя 2016, 14:24
Благодарил (а): 4 раза
Поблагодарили: 10 раз
Контактная информация:

Re: Удаленный доступ

#8

18 ноя 2016, 18:03

протокол RDP появился, окно такое. Дальше пока не пошло, покопаюсь позже — время вышло :smile:
Спасибо за помощь.


no avatar

machulan

Сообщения: 60
Зарегистрирован: 18 ноя 2016, 14:24
Благодарил (а): 4 раза
Поблагодарили: 10 раз
Контактная информация:

Re: Удаленный доступ

#9

21 ноя 2016, 11:56

Пару раз удалил / установил remmina и remmina-plugin-rdp — не работает, пишет «Ошибка SSH»
Загрузился с Live, установил remmina и remmina-plugin-rdp — все заработало
Переустановил заново Linux Mint 18 Mate 32 с того же дистрибутива, но Live создал при помощи Rufus (в прошлый раз был Linux Live USB Creator), установил сабж, все работает.
Вот и пытаюсь понять — была ли некорректная установка Linux в прошлый раз (все остальное работало без проблем) или в прошлый раз некорректно установилась remmina и удаление / переустановка положения не исправила.
Читал в описаниях, что в Linux программы удаляются полностью в отличии от Win, где создаются записи в реестре и после удаления некоторых программ реестр необходимо чистить. И обратил внимание, что данное утверждение неверно — после удаления и новой установки remmina настройки сохранялись.
Chocobo, спасибо за Вашу активность и готовность помочь :bye:


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

Nickolas

Сообщения: 436
Зарегистрирован: 14 сен 2016, 05:44
Решено: 3
Благодарил (а): 171 раз
Поблагодарили: 209 раз
Контактная информация:

Re: Удаленный доступ

#10

21 ноя 2016, 12:13

machulan писал(а): после удаления и новой установки remmina настройки сохранялись.

Интересно и где же Минт хранит эти настройки?
Это же в ручную надо чистить получается?!


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

di_mok

Сообщения: 5450
Зарегистрирован: 27 авг 2016, 19:06
Решено: 32
Откуда: Арзамас
Благодарил (а): 1580 раз
Поблагодарили: 1268 раз
Контактная информация:

Re: Удаленный доступ

#11

21 ноя 2016, 12:31

Удалит вместе с настройками

Настоящая водка — это не пьянство, а ключ к своей совести, с нее-то и начинается настоящая мудрость. (c)
Изображение


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

Chocobo

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

Re: Удаленный доступ

#12

21 ноя 2016, 12:37

Nickolas писал(а): Интересно и где же Минт хранит эти настройки?

Большинство пользовательских настроек хранятся в одноименных скрытых папках (начинающихся с точки) в домашнем каталоге.
То же и с remmina — ~/.remmina/

Изображение

   

Изображение


Skip to content



Open


Issue created Sep 07, 2016 by Fry-kun@Fry-kun

Can’t start SSH session

  • Client (OS name and version): Fedora 24
  • Remmina version (remmina —version): 1.2.0-rcgit.7
  • Desktop environment (GNOME, Unity, KDE, ..): XFCE
  • Connecting to (OS and version): Fedora 23
  • Connecting via (RDP, VNC, …): SSH+VNC

This worked in Fedora 23, stopped working in 24
The error I’m getting is

Failed to startup SSH session: crypt_set_algorithm2: no crypto
algorithm function found for chacha20-poly1305@openssh.com

Debug log:

[SSH] socket_callback_connected: Socket connection callback: 1 (0)
[SSH] ssh_client_connection_callback: SSH server banner: SSH-2.0-OpenSSH_7.2
[SSH] ssh_analyze_banner: Analyzing banner: SSH-2.0-OpenSSH_7.2
[SSH] ssh_analyze_banner: We are talking to an OpenSSH client version: 7.2 (70200)
[SSH] crypt_set_algorithms2: crypt_set_algorithms2: no crypto algorithm function found for chacha20-poly1305@openssh.com

client:

$ rpm -qa |grep libssh
libssh2-1.7.0-5.fc24.x86_64
libssh-0.7.3-1.fc24.x86_64
libssh2-1.7.0-5.fc24.i686
libssh2-devel-1.7.0-5.fc24.x86_64
$ rpm -qa |grep openssh
openssh-askpass-7.2p2-12.fc24.x86_64
openssh-7.2p2-12.fc24.x86_64
openssh-clients-7.2p2-12.fc24.x86_64
openssh-server-7.2p2-12.fc24.x86_64

client’s /etc/ssh/ssh_config:

Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr

By experimenting:

  • user ssh config is ignored; only system-wide version is used.
  • if I remove all @openssh.com ciphers from the list (so that aes256-ctr is 1st), the connection completes without errors

So, the error seems to be that the libssh library (??) only attempts to use the 1st cipher in the list and doesn’t try any of the others. Not sure if this is a problem with libssh calling convention or libssh itself (perhaps https://red.libssh.org/issues/202)

An ugly workaround for user is to adjust the ciphers — but they’d have to change ciphers for the whole system!
An ugly workaround for Remmina: write a loop and whittle down the list of ciphers until the list is exhausted or connection is made. Python/pseudocode:

ciphers = read_config()    ## "chacha20-poly1305,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr"
for cipher in ciphers.split(','):
    # just guessing here 
    ssh_options_set (ssh->session, SSH_OPTIONS_CIPHERS_C_S, cipher);
    ssh_options_set (ssh->session, SSH_OPTIONS_CIPHERS_S_C, cipher);
    if connection_established():
        break

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

Forum rules
Before you post please read how to get help. Topics in this forum are automatically closed 6 months after creation.

rebelxt

Level 2
Level 2
Posts: 67
Joined: Sat Jul 16, 2011 9:48 am

[Solved] ssh: connection timed out

I am using the Remmina remote desktop client on Linux Mint 13 Cinnamon (64 bit) to attempt to access the desktop on a Linux Mint 11 Gnome (32 bit) machine. The Remmina connection parameters include VNC, server user name, server password, server IP address, Enable SSH tunnel, and Public key. The server Remote Desktop Preferences allow other users to view the desktop.

When attempting to connect, I get this error:

Failed to startup SSH session: Timeout connecting to 192.168.1.64

Is there a log file that would have a more descriptive reason?
Is there more information I can give?

Any help is appreciated.

These are the only two machines on my home LAN.

Last edited by LockBot on Wed Dec 28, 2022 7:16 am, edited 2 times in total.

Reason: Topic automatically closed 6 months after creation. New replies are no longer allowed.

rebelxt

Level 2
Level 2
Posts: 67
Joined: Sat Jul 16, 2011 9:48 am

Re: ssh: connection timed out

Post

by rebelxt » Thu May 24, 2012 9:13 pm

This is not a Remmina problem, because I get the same result with a simple ssh command:

~ $ ssh dave@192.168.1.64
ssh: connect to host 192.168.1.64 port 22: Connection timed out

There must be something in the server system that needs to be set or reset, but I don’t know what that is.

ssh itself seems to be working:

~ $ ssh dave@localhost
The authenticity of host ‘localhost (127.0.0.1)’ can’t be established.
ECDSA key fingerprint is 95:—.
Are you sure you want to continue connecting (yes/no)? no
Host key verification failed.

The server machine is there and can be pinged:

~ $ ping -c 3 192.168.1.64
PING 192.168.1.64 (192.168.1.64) 56(84) bytes of data.
64 bytes from 192.168.1.64: icmp_req=1 ttl=64 time=0.258 ms
64 bytes from 192.168.1.64: icmp_req=2 ttl=64 time=0.272 ms
64 bytes from 192.168.1.64: icmp_req=3 ttl=64 time=0.257 ms

— 192.168.1.64 ping statistics —
3 packets transmitted, 3 received, 0% packet loss, time 1998ms
rtt min/avg/max/mdev = 0.257/0.262/0.272/0.014 ms

Image

rebelxt

Level 2
Level 2
Posts: 67
Joined: Sat Jul 16, 2011 9:48 am

rebelxt

Level 2
Level 2
Posts: 67
Joined: Sat Jul 16, 2011 9:48 am

Re: ssh: connection timed out

Post

by rebelxt » Sat May 26, 2012 6:50 am

:oops:
The server firewall was enabled. In Mint 11 Gnome, the ufw GUI dialog appears to indicate that the firewall is disabled.
It has to be unlocked to show the actual status.

Image

The following seems to be a common problem, but I have not found anything to resolve the problem in my case. I have 2 laptops ARTHUR and GALAHAD. ARTHUR is running ubuntu 16.04 (32 bit), GALAHAD is running ubuntu 18.04. I can SSH from GALAHAD to ARTHUR from a shell with no problems using Public Keys. If I try to connect to ARTHUR from GALAHAD using Remmina (via VNC) it works OK if I use password authentication in the SSH tunnelling, but this is not very secure. If I try to use Public key (automatic), after entering the SSH private key passphrase I get this message:

ssh automatic public key authentication failed: failed to read key:
/home/stuart/.ssh/authorized_keys

If instead I try to use ‘identity file’ and select ‘~/.ssh/authorized_keys’ I get the following message:

SSH public key authentication failed: Access denied.

I think this is not an SSH issue because I can connect using SSH from a shell, I think this is a Remmina issue. Any guidance would be much appreciated.

asked Mar 10, 2019 at 18:19

StuartM's user avatar

1

Probably an issue with Remmina not receiving the keys (or key-reading permissions) needed to make the connection. It sounds like:

  1. You are using the Remmina GUI, and
  2. Remmina is forcing you to configure something that the shell ssh command handles implicitly.

The second warning looks familiar: ‘identity file’ sounds like a private key. I know they call it «public key» authentication, but that may refer to ARTHUR’s point of view: it will decide whether to grant access to GALAHAD based on the public key.

authorized_keys is not a private key file; it is a list of the public keys of that can sign in as the user in whose .ssh folder it is located. The file is relevant on the receiving computer, and probably does not contain the receiving computer’s public key. If key-based SSH is working for you, then ARTHUR likely has an authorized_keys containing GALAHAD’s public key.

If key-based SSH succeeds without specifying a key, then I expect the private key to be ~/.ssh/id_rsa (public key in id_rsa.pub, should you need it). Try using that pair in Remmina.

answered Mar 11, 2019 at 0:08

MBer's user avatar

MBerMBer

2,13818 silver badges33 bronze badges


Go to Remmina


r/Remmina

Remmina is a remote desktop client written in C/GTK. Remmina supports multiple network protocols in an integrated and consistent user interface. Currently, RDP, VNC, SPICE, SSH, and HTTP are supported.

Remmina is free and open-source software, released under GNU GPL license.




Members





Online



Error when attempting to SSH to older (CentOS 6) server: «Could not start SSH session. kex error»

Full text of the error message:

Could not start SSH session. kex error : no match for method server host key algo: server [ssh-rsa,ssh-dss], client [rsa-sha2-512,rsa-sha2-256,ssh-ed25519,ecdsa-sha2-nistp521,ecdsa-sha2-nistp384,ecdsa-sha2-nistp256]

I’m assuming I’m pulling from some library on my system that deprecated ssh-rsa after the most recent update, since it started literally right after doing a dnf upgrade -y on my Fedora 36 system. I’m currently running Remmina 1.4.27, Flatpak.

  • Печать

Страницы: [1]   Вниз

Тема: Обход ошибки Remmina при соединении по SSH по ключам  (Прочитано 2463 раз)

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

Оффлайн
andy_minsk

В Remmina, на протяжении долгого времени сохраняется странный баг при соединении по ключам, который проявляется в невозможности соединения из-за отсутствия или несовпадения ключа, хотя в терминале и других клиентах все проходит нормально.
Случайно наскочил на обход данного бага, который решил проблему. Собственно описание по ссылке http://ru-root.livejournal.com/2371615.html
Достаточно было только ввести

ssh-add ~/.ssh/*.rsa (или вместо маски имя вашего ключа(ключей)), чтобы авторизация по публичному ключу начала работать правильно. Надеюсь поможет кому-то :)


Оффлайн
ArcFi

Если что, в гноме gnome-keyring это должен делать автоматом.


Оффлайн
andy_minsk

unity  :). В нем, похоже, автоматом не проходит. Во всяком случае, не на всех ssh соединениях Remmina работает по умолчанию.


Оффлайн
ArcFi

У меня примерно дюжина подключений, 4 ключа.
С указанной проблемой не сталкивался.
У вас seahorse все ключи видит?



Оффлайн
ArcFi

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

Даже без явного указания способа аутентификации / файла ключа на клиенте, так?

Просто remmina используется для многого другого и неохота зоопарк держать на машине.

Знакомая история.
Правда, у меня такая беда, что при завершении сеанса ssh (в частности, при удалённой перезагрузке), remmina частенько виснет, причём со всеми открытыми вкладками.
Поэтому для ssh приходится юзать терминал.


  • Печать

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

Go to Remmina

Error when attempting to SSH to older (CentOS 6) server: «Could not start SSH session. kex error»

Full text of the error message:

    Could not start SSH session. kex error : no match for method server host key algo: server [ssh-rsa,ssh-dss], client [rsa-sha2-512,rsa-sha2-256,ssh-ed25519,ecdsa-sha2-nistp521,ecdsa-sha2-nistp384,ecdsa-sha2-nistp256]

I’m assuming I’m pulling from some library on my system that deprecated ssh-rsa after the most recent update, since it started literally right after doing a dnf upgrade -y on my Fedora 36 system. I’m currently running Remmina 1.4.27, Flatpak.

Skip to content



Open


Issue created Aug 29, 2016 by e-alfred@e-alfred

Remmina can’t connect to system that has only modern KEX algorithms enabled using SSH

Hello,

I am getting the following error if I try to connect to a pfSense 2.3.2 instance:

Error while starting the SSH connection: kex error : no match for method mac algo client->server: server [hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-ripemd160-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160,umac-128@openssh.com], client [hmac-sha1]

pfSense disabled most old algorithms, those enabled are documented here:

https://doc.pfsense.org/index.php/2.3.2_New_Features_and_Changes#SSH_Daemon

 Changed sshd to use stronger Key Exchange algorithms and disabled some older, weaker algorithms. Clients may need to be updated to handle the new Key Exchange methods.
    Currently allowed Key Exchange Algorithms: curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256
Removed the ECDSA host key from the sshd configuration
Added ED25519 host key to the sshd configuration
Changed the list of available ciphers.
    Current allowed ciphers: chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
Changed the list of available Message Authentication Code methods,
    Current MAC list: hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-ripemd160-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160,umac-128@openssh.com

My system specs:

  • Client (OS name and version): Kubuntu 14.04.5
  • Remmina version (remmina —version): 1.2.0-rcgit-15
  • Desktop environment (GNOME, Unity, KDE, ..): KDE 4.14
  • Connecting to (OS and version): pfSense 2.3
  • Connecting via (RDP, VNC, …): SSH

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.


Description


Andrea Oliveri


2021-04-26 12:54:55 UTC

Description of problem:
Impossible to connect to servers that use old KEX algoritms
If you try to connect to (for example) RDP server through a SSH tunnel and the SSH server uses only old KEX algorithm Remmina returns 

"Could not start SSH session. kex error: no match for method server host key algo: server [ssh-rsa,ssh-dss], client [rsa-sha2-256,rsa-sha2-512,ecdsa-sha2-nistp256,ecdsa-sha2-nistp521,ssh-ed25519]"

while a ordinary ssh client is able to connects.
I think is the same as:
https://gitlab.com/Remmina/Remmina/-/issues/983


Comment 1


Simone Caronni


2021-04-27 06:05:47 UTC

Remmina uses libssh for the SSH connection, have you tried to switch from the DEFAULT crypto policy?

$ cat /usr/share/crypto-policies/DEFAULT/libssh.txt | grep Kex
KexAlgorithms curve25519-sha256,curve25519-sha256,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512

This one above is from Fedora 33, the 34 one is a bit further restrictive.


Comment 2


Andrea Oliveri


2021-04-30 09:09:43 UTC

Fedora 34 has the same output for the default crypto policy but previously, on Fedora 33, remmina worked with that server. However, if I set crypto policy to "LEGACY" it works :) thanks

  • Печать

Страницы: [1]   Вниз

Тема: Обход ошибки Remmina при соединении по SSH по ключам  (Прочитано 2399 раз)

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

Оффлайн
andy_minsk

В Remmina, на протяжении долгого времени сохраняется странный баг при соединении по ключам, который проявляется в невозможности соединения из-за отсутствия или несовпадения ключа, хотя в терминале и других клиентах все проходит нормально.
Случайно наскочил на обход данного бага, который решил проблему. Собственно описание по ссылке http://ru-root.livejournal.com/2371615.html
Достаточно было только ввести

ssh-add ~/.ssh/*.rsa (или вместо маски имя вашего ключа(ключей)), чтобы авторизация по публичному ключу начала работать правильно. Надеюсь поможет кому-то :)


Оффлайн
ArcFi

Если что, в гноме gnome-keyring это должен делать автоматом.


Оффлайн
andy_minsk

unity  :). В нем, похоже, автоматом не проходит. Во всяком случае, не на всех ssh соединениях Remmina работает по умолчанию.


Оффлайн
ArcFi

У меня примерно дюжина подключений, 4 ключа.
С указанной проблемой не сталкивался.
У вас seahorse все ключи видит?



Оффлайн
ArcFi

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

Даже без явного указания способа аутентификации / файла ключа на клиенте, так?

Просто remmina используется для многого другого и неохота зоопарк держать на машине.

Знакомая история.
Правда, у меня такая беда, что при завершении сеанса ssh (в частности, при удалённой перезагрузке), remmina частенько виснет, причём со всеми открытыми вкладками.
Поэтому для ssh приходится юзать терминал.


  • Печать

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

Ubuntu 3

Remmina is a highly popular Remote Desktop Client written in GTK+, aiming to be useful for system administrators and travelers who need to work with lots of remote computers. However, users may occasionally encounter the error message “Cannot connect to RDP server localhost.” This article will guide you through several methods to resolve this issue.

  1. Change the Security Protocol
  2. Delete the known_hosts File
  3. Recreate the Connection
  4. Check Network Security
  5. Verify Certificate Verification
  6. Check Permissions
  7. Switch Security Protocol Negotiation
  8. Use SSH Tunneling

Change the Security Protocol

One of the first steps you can take is to change the security protocol in Remmina’s connection properties.

  1. Open Remmina and navigate to the connection properties.
  2. Go to the “Advanced” tab.
  3. Change the security protocol from “Negotiate” to “TLS” or “RDP.”

The security protocol is responsible for establishing a secure connection between your client and the server. By changing it, you may resolve any issues causing the error.

Delete the known_hosts File

If the keys on the tunnel server have changed, you may encounter connection issues. To resolve this, you can delete the known_hosts file. The file location may vary depending on your setup.

To delete the file, open your terminal and input the following command:

rm ~/.freerdp/known_hosts

or

rm ~/.config/freerdp/known_hosts

The rm command is used to remove files or directories in Linux. The ~ symbol represents your home directory, and the .freerdp/known_hosts is the path to the file you want to delete.

Recreate the Connection

If you’ve copied your Remmina configuration from one machine to another, it may cause compatibility issues. In this case, deleting and recreating the connection can resolve the problem.

Check Network Security

Ensure that you are connected to a secure Wi-Fi network. Connecting through an open, unencrypted network may cause connection problems. Switching to a secure network can help resolve the issue.

Verify Certificate Verification

In Remmina’s connection properties, go to the “Advanced” tab and check the “Ignore certificate” option. This can help if there are certificate verification issues. However, be cautious as disabling certificate verification can expose you to potential security risks.

Check Permissions

If you are using the snap version of Remmina and encounter permission denied errors, it may indicate a permissions issue. Uninstalling and reinstalling Remmina from the snap store or installing it from the repository can help resolve the problem.

Switch Security Protocol Negotiation

In Remmina’s connection properties, go to the “Advanced” tab and change the “Security protocol negotiation” from “TLS protocol security” to “RDP protocol security.” This solution has worked for some users.

Use SSH Tunneling

If all else fails, you can try establishing an SSH tunnel manually using the command:

ssh -L 2000:<ip of windows machine>:3389 bastion

And configure Remmina to connect to localhost:2000 using RDP. The -L option specifies that the given port on the local (client) host is to be forwarded to the given host and port on the remote side.

Remember, it’s important to carefully follow the instructions and consider the security implications of the solutions provided. With these steps, you should be able to resolve the “Cannot connect to RDP server localhost” error in Remmina.

Remmina is a Remote Desktop Client written in GTK+ that allows users to connect and work with remote computers.

To change the security protocol in Remmina, open the connection properties, go to the «Advanced» tab, and select the desired security protocol from the dropdown menu.

The location of the known_hosts file may vary depending on your setup. In most cases, it can be found in either ~/.freerdp/known_hosts or ~/.config/freerdp/known_hosts.

To delete the known_hosts file, open your terminal and use the rm command followed by the path to the file. For example, rm ~/.freerdp/known_hosts or rm ~/.config/freerdp/known_hosts.

If you experience compatibility issues after copying your Remmina configuration, it is recommended to delete and recreate the connection on the new machine to resolve any problems.

Open, unencrypted Wi-Fi networks are less secure and can pose potential risks. It is advised to connect to a secure Wi-Fi network to avoid connection problems.

In Remmina’s connection properties, go to the «Advanced» tab and check or uncheck the «Ignore certificate» option to enable or disable certificate verification.

Permission denied errors in the snap version of Remmina may indicate a permissions issue. Try uninstalling and reinstalling Remmina from the snap store or installing it from the repository to resolve the problem.

Понравилась статья? Поделить с друзьями:
  • Resident evil 2 remake ошибка hresult 0x887a0005
  • Resident evil hd remaster русификатор ошибка
  • Resident evil village ошибка concrt140 dll
  • Resident evil 2 remake ошибка directx 12
  • Remember me ошибка при запуске приложения 0xc000007b