Содержание
- Unable to connect to SSH using authentication by public key
- Local System Description
- Remote System Description
- Problem Description
- What is the expected correct behavior?
- SSH connection refused — after recent upgrade to Ubuntu 18.10
- Local System Description
- Remote System Description
- Problem Description
- remmina больше не работает «невозможно подключиться к локальному хосту RDP-сервера»
- 18 ответов
- ОБНОВИТЬ
- Remmina SSH identity file can’t connect with blank password
- Local System Description
- Remote System Description
- Problem Description
- What is the expected correct behavior?
- Relevant logs and/or screenshots
- SSH public key cannot be imported: Access denied for ‘none’. Authentication that can continie: publickey
- Local System Description
- Remote System Description
- Problem Description
Unable to connect to SSH using authentication by public key
Local System Description
- Client (OS name and version): Xubuntu 20.04.1
- Remmina version ( remmina —version ): 1.4.10 (git 717708b1)
- Installation:
- Distribution package.
- PPA.
- Snap.
- Flatpak.
- Compiled from sources.
- Other — detail:
- Desktop environment (GNOME, Unity, KDE, ..): Xfce 4.14
- Plugin:
- RDP — freerdp version ( xfreerdp —version ):
- VNC
- SSH
- SFTP
- SPICE
- WWW
- EXEC
- Other (please specify):
- GTK back-end (Wayland, Xorg): Xorg
- Optional: Include the output of the following commands at the end of this text:
remmina —full-version
Remote System Description
- Server (OS name and version): Linux
- Special notes regarding the remote system (i.e. gateways, tunnel, etc.): —
Problem Description
I have SSH connection defined.
When I use Authentication type: Password, it works fine.
But I was unable to connect, when I selected Authentication type: Public key (automatic).
I’m also able to connect via console using ssh to the same server — using
/.ssh/id_rsa .
So connection to server and authentication is OK.
- First of all I have problem reading file
/.ssh/id_rsa in snap version. I’ve tried to set all permissions to enabled:
Snap Permissions
But still I’ve got errors reading file
Debug log (Personal data replaced with ###)
- Then I’ve tried temporary workaround by copying keys to folder
But I was unable to connect to server anyway.
Debug log (Personal data replaced with ###)
I can see, that it won’t read
/.ssh/ , but try using
/snap/remmina/common/.ssh/ instead.
Still when I’ve copied files there, there is permission error. I even tried to change file attributes to 777, without success.
One thing that is strange is somehow old version of libssh 0.7.0 .
The one used in other packages (NONsnap) is current libssh 0.9.5 .
But maybe it is just some other issue, rather than source of problem itself.
I also tried «latest» snap-edge version: v1.4.10+git120.9ca6a7bd => same problem.
/var/log/syslog is showing show some denied operations.
/var/log/syslog (Personal data replaced with ###)
What is the expected correct behavior?
Successfully connect to SSH server using public key authentication using standard file from my home folder ( .ssh ).
Источник
SSH connection refused — after recent upgrade to Ubuntu 18.10
Local System Description
Ubuntu just upgraded to 18.10 when problem started.
- Client (OS name and version):ubunt8 18.10
- Remmina version ( remmina —version ):Remmina — 1.3.4
- Installation mean:
- Distribution package.
- PPA.
- Snap.
- Flatpak.
- Compiled from sources.
- Other — detail:
- Desktop environment (GNOME, Unity, KDE, ..):XFCE and Ubuntu Gnome
- Plugin:
- [] RDP — freerdp version ( xfreerdp —version ):
- VNC
- SSH
- SFTP
- SPICE
- EXEC
- Other (Please specify):
- Gtk Backend (Wayland, Xorg, ??): Xorg
- Optional: include the output of the following commands at the end of this text:
- remmina —full-version StatusNotifier/Appindicator support: not supported by desktop. libappindicator will try to fallback to GtkStatusIcon/xembed
Remmina — 1.3.4 (git n/a) NAME TYPE DESCRIPTION PLUGIN AND LIBRARY VERSION RDP Protocol RDP — Remote Desktop Protocol RDP Plugin: 1.3.4 (git n/a), Compiled with FreeRDP lib: 2.0.0-dev5 (n/a), Running with FreeRDP lib: 2.0.0-dev5 (rev n/a), H264: Yes RDPF File RDP — RDP File Handler RDP Plugin: 1.3.4 (git n/a), Compiled with FreeRDP lib: 2.0.0-dev5 (n/a), Running with FreeRDP lib: 2.0.0-dev5 (rev n/a), H264: Yes RDPS Preference RDP — Preferences RDP Plugin: 1.3.4 (git n/a), Compiled with FreeRDP lib: 2.0.0-dev5 (n/a), Running with FreeRDP lib: 2.0.0-dev5 (rev n/a), H264: Yes SFTP Protocol SFTP — Secure File Transfer 1.3.4
SSH Protocol SSH — Secure Shell 1.3.4
VNC Protocol VNC — VNC viewer 1.3.4
VNCI Protocol VNCI — VNC viewer listen mode 1.3.4
glibsecret Secret Secure passwords storing in the GNOME keyring 1.3.4
Build configuration: HAVE_ARPA_INET_H=1 HAVE_ERRNO_H=1 HAVE_FCNTL_H=1 HAVE_NETDB_H=1 HAVE_NETINET_IN_H=1 HAVE_NETINET_TCP_H=1 HAVE_SYS_SOCKET_H=1 HAVE_SYS_UN_H=1 HAVE_TERMIOS_H=1 HAVE_UNISTD_H=1 WITH_APPINDICATOR=ON WITH_AVAHI=ON WITH_FREERDP=ON WITH_GCRYPT=ON WITH_GETTEXT=ON WITH_IPP=OFF WITH_LIBRARY_VERSIONING=ON WITH_LIBSECRET=ON WITH_LIBSSH=ON WITH_LIBVNCSERVER=ON WITH_MANPAGES=ON WITH_SPICE=ON WITH_SSE2=ON WITH_TELEPATHY=ON WITH_TRANSLATIONS=ON WITH_VTE=ON Build type: None CFLAGS: -g -O2 -fdebug-prefix-map=/build/remmina-1tzAJ_/remmina-1.3.4+ppa201903130044.r494903ec.d3617f3c
ubuntu18.10.1=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -Wall -g Compiler: GNU, 8.2.0 Target architecture: x64
- sudo lshw -C video
- uname -a Linux 4.18.0-18-generic #19 (closed)-Ubuntu SMP Tue Apr 2 18:13:16 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
Remote System Description
- Server (OS name and version): several : Raspbian stetch, Mate, Ubuntu 19.04 all impacted same
- Special notes regarding the remote system (i.e. gateways, tunnel, etc): different ports on each
Problem Description
After upgrade to 18.10 which involved resolving issue like #1744 (closed) I found I could not SSH into any of my servers, but could still do so with CLI SSH.
Write here a detailed description of the problem/request. Remmina reports ‘failed to start SSH session connection refused. I checked ports were open (CLI SSH works), rebooted, check passwords, UFW, fail2ban etc and tried making new entries in Remmina but nothing worked. Log window gives this:
I tried checking .ssh/sshd_config but it seems OK, but I no expert so any advice welcome.
Источник
remmina больше не работает «невозможно подключиться к локальному хосту RDP-сервера»
До прошлой ночи у меня была Реммина, работающая нормально. Я мог запустить RDP через туннель SSH, и все было хорошо.
Тогда это перестало работать. Я могу добраться до диалогового окна пароля для моей рабочей машины, но тогда он просто говорит Cannot connect to RDP server localhost ,
Я даже не могу найти журналы, которые выглядят интересно. Я восстановил Remmina, очистил мой .remmina каталог, перезапустил мою машину и даже перезапустил мой шлюз.
Просто чтобы сделать это действительно странным, мой ноутбук (который имеет ту же настройку — последние версии Ubuntu и Remmina) может установить соединение просто отлично. Он даже проходит через тот же маршрутизатор, хотя и по беспроводной сети.
18 ответов
Я понятия не имею, почему это работает, но я начал менять настройки по одному. Когда я отредактировал свойства соединения, я посмотрел на вкладку «Дополнительно» и изменил безопасность с «согласовать» на «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 года в 18:55
Источник
Remmina SSH identity file can’t connect with blank password
Consider to test the latest Remmina version before to submit a bug report At the moment the latest version available is v1.4.0
If this is not a bug, submit your question to our reddit or our general discussion mailing list. Sometimes you can find us on IRC, we are on freenode.net , in the channel #remmina.
Local System Description
Client (KDE Neon): .—. « -:-. OS: KDE neon User Edition 5.18 x86_64 :/: .—-//—-. :/- Host: XPS 8700 . — —. .: Kernel: 5.3.0-40-generic .: — .:- :. Uptime: 6 hours, 4 mins / :. .-::-. -: / Packages: 2021 /. /. :++++++++: .: .: Shell: bash 4.4.20 / .: +++++++++++/ / + Resolution: 1920×1200, 1920×1200, 1920×1200 /+ — .++++++++++++ :. .+: DE: KDE / .: +++++++++++/ / + WM: KWin / /. :++++++++: .: .: WM Theme: Mondrian ./ :. . -. -: / Theme: Materia Dark [KDE], Breeze [GTK2/3] .: — .:- :. Icons: Materia-Manjaro-Breeze-Dark [KDE], Materia-Manjaro-Breeze-Dark [GTK2/3] . — —. .: Terminal: konsole :/: .—-//—-. :/- CPU: Intel i7-4790 (8) @ 4.000GHz .-:. « -:-. GPU: NVIDIA GeForce GTX 745 —.« « .—.` Memory: 4316MiB / 15964MiB
Remmina version ( remmina —version ): org.remmina.Remmina — 1.4.0 (git n/a)
- Distribution package.
- PPA.
- Snap.
- Flatpak.
- Compiled from sources.
- Other — detail:
Desktop environment (KDE):
- RDP — freerdp version ( xfreerdp —version ):
- VNC
- SSH
- SFTP
- SPICE
- WWW
- EXEC
- Other (Please specify):
Gtk Backend (Xorg): Xorg
Optional: include the output of the following commands at the end of this text:
Remote System Description
- Server (OS name and version): Windows 2019 Server
- Special notes regarding the remote system (i.e. gateways, tunnel, etc): SSH Tunnel with private key with no password
Problem Description
SSH Tunnel with private key with a blank password fails to connect on version 1.4. Same steps work for v1.2. Asks for SSH tunnel credentials, I provide a blank password and click OK. a connection attempt is made and fails.
What is the expected correct behavior?
It should allow blank password and saving of a blank password for the private key file.
Relevant logs and/or screenshots
Where do I go to find relevant logs for the issue?
Источник
SSH public key cannot be imported: Access denied for ‘none’. Authentication that can continie: publickey
Local System Description
- Client: Linux Mint 19.1 Tessa
- Remmina version ( 1.3.3 ):
- Installation mean:
- Distribution package.
- PPA.
- Snap.
- Flatpak.
- Compiled from sources.
- Other — detail:
- Desktop environment (GNOME, Unity, KDE, ..):
- Plugin:
- RDP — freerdp version ( x 1.1.0-beta1 ):
- VNC
- SSH
- SFTP
- SPICE
- EXEC
- Other (Please specify):
- Gtk Backend: Caja 1.20.2
- Optional: include the output of the following commands at the end of this text:
- remmina —full-version fullverison
- sudo lshw -C video lshw_-C_video
- uname -a Linux 4.15.0-46-generic #49-Ubuntu SMP Wed Feb 6 09:33:07 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
Remote System Description
- Server: Debian 9
- Special notes regarding the remote system (i.e. gateways, tunnel, etc): network computer (gateway)
Problem Description
Remmia 1.3.3 can’t find the key!
**In Remmia 1.3.2 this problem not exist! ** I have an other computer with installed Remmia ver. 1.3.2.
Источник
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.
- Печать
Страницы: [1] Вниз
Тема: Обход ошибки Remmina при соединении по SSH по ключам (Прочитано 2312 раз)
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] Вверх
|
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 |
Тема: SSH, проблема с публичным ключом в Remmina (Прочитано 3724 раз)
0 Пользователей и 1 Гость просматривают эту тему.
Столкнулся в версии Runtu 14.04.2
При этом через grsync, терминал и thunar все нормально.
В Remmina выдает такое и в терминале, и через shtp
А в режиме быстрого подключения предагает лишь через пароль, а не публичный ключ. Но соединия также нет.
В режиме «удаленного рабочего стола» соединение через Remmina есть.
Раньше все это работало, а проблема обнаружилась лишь на версии 14.04.02. Пробовал remmina и из родного репа, и из последних версий в стороннем ppa .
Пробовал через Putty. Через публичный ключ не хочет — предлагает через пароль и нормально соединяет.
« Последнее редактирование: Апрель 07, 2015, 10:19:46 от ek-nfn »
Записан
Devuan ASCII x32..x64
ek-nfn, попробуйте выполнить команду
ssh-add ~/.ssh/*.rsaи проверить подключение.
Записан
у меня ключ dsa. На сервер он нормально добавился в ~/.ssh/authorized_keys (иначе бы отсутствовало соединение через терминал, ФМ и rsync)
Записан
Devuan ASCII x32..x64
Записан
я удалил новую версию (из ppa от https://launchpad.net/ ) и заново установил из родного репа. Со второго запуска заработало.
Странно, эту версию я уже переустанавливал в синаптике (без удаления) и не работало.
Видимо есть разница в таких переустановках ?
Записан
Devuan ASCII x32..x64
Странно, эту версию я уже переустанавливал в синаптике (без удаления) и не работало.
Видимо есть разница в таких переустановках ?
Любая переустановка — сначала удаление, затем установка пакета. Чаще всего проблема не в файлах пакета, а в файлах конфигурации в домашнем каталоге (реже в /etc, если конфиг общесистемный). Для начала всегда нужно удалять их, а не переустанавливать весь пакет.
Записан
Чаще всего проблема не в файлах пакета, а в файлах конфигурации в домашнем каталоге
там же лишь пользовательские настройки.. 
я никогда их не удаляю, кочуют во все новые переустановки еще с версий 12.04.
но учту.. похоже нестабильность работы remmina пока сохраняется.
а что посмотреть в /etc ?
Записан
Devuan ASCII x32..x64
я никогда их не удаляю, кочуют во все новые переустановки еще с версий 12.04.
Иногда конфигурационные файлы предыдущей версии ПО несовместимы с новыми, вследствие чего могут появляться подобного рода проблемы. Если есть такое подозрение, нужно пробовать на новом (чистом) пользовательском профиле.
а что посмотреть в /etc ?
В данном случае ничего — я имел ввиду общий случай, когда программа имеет конфиги в /etc.
Записан
Иногда конфигурационные файлы предыдущей версии ПО несовместимы с новыми, вследствие чего могут появляться подобного рода проблемы. Если есть такое подозрение, нужно пробовать на новом (чистом) пользовательском профиле.
теперь мне понятно, почему бывают глюки на новых версиях приложенй 
А я откатываюсь на старые в таком случае. Спасибо за информацию.
В данном случае ничего — я имел ввиду общий случай, когда программа имеет конфиги в /etc.
Синаптик же в режиме «полного» удаления приложения помечает для удаления и системные конфиги ?
Я всегда их удаляю даже при переустановке через удаление. Не трогаю лишь пользовательские из /home/…
Записан
Devuan ASCII x32..x64
Все же Remmina продолжает глючить в режиме SSH . Переустанавливал начистую с удаленем всех конфигов.
Вообще заметил, что 14.04.2 вынудило переустановить некоторый софт. Причем некоторый из него пришлось ставить не из PPA (c более свежими версиями), а из родного репа, иначе глюкавило. Версия 14.04.1 была менее капризной.
Записан
Devuan ASCII x32..x64
0
1
День добрый! Подскажите пожалуйста. У меня проблемы с remmina, при попытки подключиться к SSH серверу с авторизацией по ключам вылетает ошибка: «Аутентификация по публичному ключу SSH не удалась: Public key file doesn’t exist». Не понятно какой публичный ключ, ведь я авторизируюсь с помощью приватного ключа, путь к которому указываю в самой программе. Версия remmina 0.9.3-2
- Ссылка
Ответ на:
комментарий
от zgen 20.10.11 23:21:22 MSK
Да. Через консоль нормально подключаюсь с указанием приватного ключа. Перепробовал многое, ничего не помогает, надо это все для того чтоб ssh тунель сама реммина открывала (Подключаюсь по RDP через SSH тунель).
- Показать ответ
- Ссылка
Ответ на:
комментарий
от shooroop-ss 20.10.11 23:41:31 MSK
Ответ на:
комментарий
от ZuBB 21.10.11 00:11:38 MSK
Создал нового пользователя, сгенерировал новую пару ключей (id_rsa/id_rsa.pub). С консоли пускает с реммины нет.
- Ссылка
Ответ на:
комментарий
от Deleted 21.10.11 01:05:46 MSK
В данный момент версия libssh 0.5.2-1 Тоже грешил на libssh пробовал разные версии ставить не помогло
- Ссылка
Всем спасибо, разобрался. Надо что бы ключи по правильному назывались и при этом публичный ключ должен лежать именно в ~/.ssh/ в таком варианте заработало
- Показать ответ
- Ссылка
30 ноября 2011 г.
Ответ на:
комментарий
от shooroop-ss 21.10.11 13:19:48 MSK
А можно по подробнее, особенно про «чтобы ключи по правильному назывались». А то мучусь с тем же.
Milker ★
(30.11.11 10:20:14 MSK)
- Показать ответ
- Ссылка
Ответ на:
комментарий
от Milker 30.11.11 10:20:14 MSK
Ответ на:
комментарий
от shooroop-ss 08.12.11 01:06:05 MSK
Ответ на:
комментарий
от Milker 28.12.11 17:13:02 MSK
Не в курсе
Не знаю, надобности не было. Пока проверить не могу.
- Ссылка
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
Похожие темы
-
Форум
Putty -> SSH Прошу объяснить мне… (2010) -
Форум
SSH авторизация по ключу (2018) -
Форум
Проблема с ssh-авторизацией по ключам (2012) -
Форум
Перенос ключей SSH (2017) -
Форум
Два вопроса насчет ssh подключения (2022)
-
Форум
ssh авторизация по ключам (2012) -
Форум
Помогите разобраться с авторизацией по ключу SSH (2017) -
Форум
ssh — авторизация по ключам (2008) -
Форум
ssh key based authentication (2016) -
Форум
ssh, рутовый доступ, авторизация по публичным ключам (2004)
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
:
-
-
December 5 2011, 19:12
- IT
- Cancel
Всем доброго времени суток. Собственно не работает сабж. На серверах настроена авторизация по ключу. Если подключаюсь из консоли, то все ок, авторизация проходит по ключу. В remmina если указать определенный ключ для авторизации на сервере, то выдает ошибку авторизации. Пишет что публичный ключ не существует. Publick key file doesn’t exist.
Уже обгуглился по данному вопросу. Инфы мало очень и народ не знает как это лечить, либо у кого-то оно вылечилось магическим способом.
Может кто-то в сообществе пользуется Remmina и получилось настроить авторизацию по ключам в SSH? Буду очень признателен за помощь, ибо достало держать в голове пароли и набирать каждый раз их при подключении.
UPD: Вот накопал, на багтрекере Remina, данная проблема уже много месяцев висит без ответа и без каких либо исправлений.
UPD2: Собственно я вышел из ситуации. Немного не так как хотел, но все же. В общем при залогинивании на своем буке сделал что бы добавлялись все приватные ключи в агента, через ssh-add ~/.ssh/*.rsa далее в настроках ssh авторизации Remmina, указал авторизацию по ключу (автоматически). Теперь Remmina нормально подхватывает нужный ключ из агента и проходит авторизацию.
Как правильно задавать вопросы
Правильно сформулированный вопрос и его грамотное оформление способствует высокой вероятности получения достаточно содержательного и по существу ответа. Общая рекомендация по составлению тем: 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 независимо от того, имеет ли это отношение к вопросу или нет. Так же не забываем об общих правилах Как пример вот
-
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
- Сообщения: 9952
- Зарегистрирован: 27 авг 2016, 22:57
- Решено: 214
- Откуда: НН
- Благодарил (а): 794 раза
- Поблагодарили: 2979 раз
- Контактная информация:
Re: Удаленный доступ
#2
18 ноя 2016, 16:16
machulan писал(а): но в терминале остается запись об ошибке.
Её стоило бы указать.
Встречный вопрос, к каким осям цепляемся?
и почему, если rdp то не remmina ? 
-
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
- Сообщения: 9952
- Зарегистрирован: 27 авг 2016, 22:57
- Решено: 214
- Откуда: НН
- Благодарил (а): 794 раза
- Поблагодарили: 2979 раз
- Контактная информация:
Re: Удаленный доступ
#4
18 ноя 2016, 16:50
machulan писал(а): До remmina не дошел,
Самый беспроблемный клиент, по опыту)
Ошибка с керберосом — это что-то на тему доменной связности.
-
machulan
- Сообщения: 60
- Зарегистрирован: 18 ноя 2016, 14:24
- Благодарил (а): 4 раза
- Поблагодарили: 10 раз
- Контактная информация:
Re: Удаленный доступ
#5
18 ноя 2016, 17:25
Вспоминаю, что в прошлый подход к линуксу минт 17,2 я использовал ремину. Сейчас запустил, но что-то не учел в настройках. Помню, в прошлый раз что-то касалось SSH… Сейчас на первом экране — RDP, в «параметры удаленного рабочего стола» — протокол SSH, сервер — …, Кодировка — ASCII (?), имя пользователя, пароль. В «правка/параметры» ничего не менял, кроме «Локальный порт SSH-туннеля» — махнул случайно и не помню, что было по умолчанию. При попытке подключения показывает «Ошибка при запуске сеанса SSH: Timeout…» Не подскажете с настройками ?
-
Chocobo
- Сообщения: 9952
- Зарегистрирован: 27 авг 2016, 22:57
- Решено: 214
- Откуда: НН
- Благодарил (а): 794 раза
- Поблагодарили: 2979 раз
- Контактная информация:
Re: Удаленный доступ
#6
18 ноя 2016, 17:53
machulan писал(а): Ошибка при запуске сеанса SSH: Timeout..
протокол должен быть доступен rdp, доставь пакетик remmina-plugin-rdp
-
machulan
- Сообщения: 60
- Зарегистрирован: 18 ноя 2016, 14:24
- Благодарил (а): 4 раза
- Поблагодарили: 10 раз
- Контактная информация:
Re: Удаленный доступ
#7
18 ноя 2016, 17:54
ок, сейчас попробую
-
machulan
- Сообщения: 60
- Зарегистрирован: 18 ноя 2016, 14:24
- Благодарил (а): 4 раза
- Поблагодарили: 10 раз
- Контактная информация:
Re: Удаленный доступ
#8
18 ноя 2016, 18:03
протокол RDP появился, окно такое. Дальше пока не пошло, покопаюсь позже — время вышло
Спасибо за помощь.
-
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, спасибо за Вашу активность и готовность помочь 
-
Nickolas
- Сообщения: 436
- Зарегистрирован: 14 сен 2016, 05:44
- Решено: 3
- Благодарил (а): 169 раз
- Поблагодарили: 209 раз
- Контактная информация:
Re: Удаленный доступ
#10
21 ноя 2016, 12:13
machulan писал(а): после удаления и новой установки remmina настройки сохранялись.
Интересно и где же Минт хранит эти настройки?
Это же в ручную надо чистить получается?!
-
di_mok
- Сообщения: 5436
- Зарегистрирован: 27 авг 2016, 19:06
- Решено: 32
- Откуда: Арзамас
- Благодарил (а): 1568 раз
- Поблагодарили: 1258 раз
- Контактная информация:
Re: Удаленный доступ
#11
21 ноя 2016, 12:31
Удалит вместе с настройками
Настоящая водка — это не пьянство, а ключ к своей совести, с нее-то и начинается настоящая мудрость. (c)
-
Chocobo
- Сообщения: 9952
- Зарегистрирован: 27 авг 2016, 22:57
- Решено: 214
- Откуда: НН
- Благодарил (а): 794 раза
- Поблагодарили: 2979 раз
- Контактная информация:
Re: Удаленный доступ
#12
21 ноя 2016, 12:37
Nickolas писал(а): Интересно и где же Минт хранит эти настройки?
Большинство пользовательских настроек хранятся в одноименных скрытых папках (начинающихся с точки) в домашнем каталоге.
То же и с remmina — ~/.remmina/
26 мая, 2017 12:02 пп
14 071 views
| Комментариев нет
Linux, SSH, VPS
В первой статье этой серии вы узнали о том, как и в каких ситуациях вы можете попробовать исправить ошибки SSH. Остальные статьи расскажут, как определить и устранить конкретные ошибки:
- Проблемы с подключением к серверу: здесь вы узнаете, как обнаружить и исправить ошибки подключения к серверу.
- Ошибки аутентификации: поможет устранить проблемы с парольной аутентификацией или сбросом SSH-ключей.
- Ошибки оболочки: это руководство поможет исправить ошибки ветвления процессов, валидации оболочки и доступа к домашнему каталогу.
В данном руководстве вы узнаете, что делать, если сбрасываются клиентские соединения, клиент жалуется на шифрование или возникают проблемы с неизвестным или измененным удаленным хостом.
После успешного подключения протокол SSH согласовывает зашифрованное соединение с клиентом на основе установления доверия. Есть несколько уникальных проблем, которые могут возникнуть на этом этапе. В этом мануале рассматриваются способы их определения, устранения и предотвращения.
Требования
- Убедитесь, что можете подключиться к виртуальному серверу через консоль.
- Проверьте панель на предмет текущих проблем, влияющих на работу и состояние сервера и гипервизора.
Общие ошибки
Ошибка при проверке ключа хоста
Когда к серверу подключается SSH-клиент, сервер пытается идентифицировать себя с помощью ключа хоста. Если главный ключ изменился, вы можете увидеть такое предупреждение:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
...
В PuTTY предупреждение выглядит так:
WARNING - POTENTIAL SECURITY BREACH!
The server's host key does not match the one PuTTY has
cached in the registry. This means that either the
Server administrator has changed the host key, or you
...
Обычно причиной этой ошибки является:
- Восстановление сервера с помощью снапшота или резервной копии.
- Перенос плавающего IP на другой сервер.
- Переустановка SSH-сервера с помощью менеджера пакетов
Чтобы решить эту проблему, вы можете очистить ключи хоста.
Соединение закрыто или сброшено
Иногда соединения устанавливаются на уровне сокета, но сбрасываются во время проверки ключей хоста. В PuTTY эта ошибка выглядит так:
Server Unexpectedly closed network connection
Клиент OpenSSH выдаёт такую ошибку:
Connection closed by 111.111.111.111 port 22
Эта ошибка, как правило, происходит по следующим причинам:
- Сбой или ошибки сервиса SSH.
- Сервис SSH не может инициализировать подключение из-за отсутствия ключей хоста сервера.
В таком случае необходим более тщательный анализ выходных данных протокола. В большинстве случаев данные нужно исследовать через веб-консоль и убедиться, что сервис в данный момент запущен и связан с требуемым портом.
Если сервис работает должным образом, убедитесь, что ключи хоста доступны. Если это не так, сгенерируйте и снова.
Ошибки переговоров с хостом
При инициировании протокола SSH генерируется общий секретный ключ. Это делается посредством шифрования, согласованного между клиентом и хостом. Если на данном этапе возникает несоответствие, переговоры срываются, и вы можете увидеть такие ошибки в PuTTY:
Couldn't agree a client-to-server cipher (available: aes128-ctr, aes192-ctr, aes256-ctr)
Клиент OpenSSH сообщит:
Unable to negotiate with 111.111.111.111: no matching key exchange method found.
Their offer: diffie-hellman-group1-sha1
Источником этой ошибки может быть:
- Несовпадение реализаций клиента и хоста (если вы используете современный клиент OpenSSH и устаревший хост, последний может просто не поддерживать шифрования клиента).
- Изменение списка шифрования клиента SSH (возможно, сервер его не поддерживает).
Чтобы решить эту проблему, вам необходимо правильно настроить шифрование на SSH-клиенте.
Устранение неполадок
Сброс ключей известных хостов
Ключи хоста обычно хранятся в файле ~/.ssh/known_hosts клиента OpenSSH. PuTTY обычно хранит их в реестре Windows (HKEY_CURRENT_USERSoftwareSimonTathamPuTTYSshHostKeys).
В PuTTY можно использовать диалоговое окно, чтобы разрешить подключение и обновить реестр (просто выберите Yes). Кроме того, вы можете удалить запись вручную.
На клиенте OpenSSH вы можете найти записи хоста в файле ~/.ssh/known_hosts и удалить их вручную. Также можно использовать команду ssh-keygen.
ssh-keygen -R your_server_ip
Команда попытается получить доступ и очистить соответствующую запись хоста в файле known_hosts:
# Host 111.111.111.111 found: line 2
/home/user/.ssh/known_hosts updated.
Original contents retained as /home/user/.ssh/known_hosts.old
После этого попробуйте снова подключиться к серверу.
Проверка и генерирование SSH-ключей
Если у хоста SSH нет собственного закрытого ключа и он не может сгенерировать общий секретный ключ, соединение будет сброшено. Откройте каталог /etc/ssh и попробуйте найти в нём группу файлов с именами sshd_host_*_key. Среди них должен быть файлы с расширением .pub.
Если таких файлов нет, сгенерируйте их с помощью команды ssh-keygen.
ssh-keygen -A
Команда выведет сгенерированные ключи:
ssh-keygen: generating new host keys: RSA DSA ECDSA ED25519
Теперь попробуйте снова подключиться к серверу.
Настройка поддерживаемых шифров SSH
Вы можете настроить поддерживаемые SSH-шифры на клиентской машине, если нужна поддержка устаревшего шифрования (например, SHA1). Это не очень распространенная проблема; обычно она случается, если вы используете новый клиент SSH для подключения к устаревшему SSH-серверу, и они поддерживают разные шифры.
В OpenSSH поддержку SHA1 можно настроить с помощью опции KexAlgorithms. Введите в командную строку:
openssh -oKexAlgorithms=+diffie-hellman-group1-sha1 root@your_server_ip
Клиент PuTTY должен поддерживать группу Диффи-Хеллмана (Connection → SSH → Kex).
Если у вас не получается самостоятельно исправить ошибки протокола SSH, вы можете обратиться за помощью к службе поддержки своего хостинг-провайдера.
Tags: OpenSSH, PuTTY, SSH