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.
- Печать
Страницы: [1] Вниз
Тема: Обход ошибки Remmina при соединении по SSH по ключам (Прочитано 2387 раз)
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] Вверх
Open
Issue created Aug 29, 2016 by
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 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
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.
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 |
pcjunki@homepc:~$ /usr/sbin/sshd -T | sort | less
Could not load host key: /etc/ssh/ssh_host_rsa_key
Could not load host key: /etc/ssh/ssh_host_dsa_key
Could not load host key: /etc/ssh/ssh_host_ecdsa_key
Could not load host key: /etc/ssh/ssh_host_ed25519_key
acceptenv LANG
acceptenv LC_*
addressfamily any
allowstreamlocalforwarding yes
allowtcpforwarding yes
authenticationmethods
authorizedkeysfile .ssh/authorized_keys .ssh/authorized_keys2
challengeresponseauthentication no
ciphers 3des-cbc,blowfish-cbc,cast128-cbc,arcfour,arcfour128,arcfour256,aes128-cbc,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com
clientalivecountmax 3
clientaliveinterval 0
compression delayed
gatewayports no
gssapiauthentication no
gssapicleanupcredentials yes
gssapikeyexchange no
gssapistorecredentialsonrekey no
gssapistrictacceptorcheck yes
hostbasedauthentication no
hostbasedusesnamefrompacketonly no
hostkey /etc/ssh/ssh_host_dsa_key
hostkey /etc/ssh/ssh_host_ecdsa_key
hostkey /etc/ssh/ssh_host_ed25519_key
hostkey /etc/ssh/ssh_host_rsa_key
ignorerhosts yes
ignoreuserknownhosts no
ipqos lowdelay throughput
kbdinteractiveauthentication no
kerberosauthentication no
kerberosorlocalpasswd yes
kerberosticketcleanup yes
kexalgorithms diffie-hellman-group1-sha1,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group-exchange-sha256,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group1-sha1,curve25519-sha256@libssh.org
keyregenerationinterval 3600
listenaddress 0.0.0.0:22
listenaddress [::]:22
logingracetime 120
loglevel INFO
macs hmac-sha1,hmac-sha1-96,hmac-sha2-256,hmac-sha2-512,hmac-md5,hmac-md5-96,hmac-ripemd160,hmac-ripemd160@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha1-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-md5-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-ripemd160-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com
maxauthtries 6
maxsessions 10
maxstartups 10:30:100
passwordauthentication yes
permitemptypasswords no
permitopen any
permitrootlogin without-password
: