SSH Tunneling is broken with SSH Agent with public key
Created by: mattpepin
Version 1.2.0-rcgit-19 broke SSH tunneling using a public key with SSH Agent. My passphrase is never asked and no error message is displayed (no dialog box, no log message in a console window. Public key (automatic) works, but I don't want Remmina to manage my keys.
Activity
Created by: mattpepin
No worries, I'll use an older package for now (I'm on Arch linux, but I found a question about this on Askubuntu: https://askubuntu.com/questions/939524/remmina-1-2-ssh-authentication-options).
In my case, it won't work even if I used my key earlier (passphrase in memory).
-
We use libssh behind remmina and as you can see in the doc:
Tries to automatically authenticate with public key and "none".
It may fail, for instance it doesn't ask for a password and uses a default asker for passphrases (in case the private key is encrypted).So it's the right behavior, in fact it works when the gnome keyring has stored the password, but it's quite confusing.
I'll investigate further if it's possible to simplify it or rollback it somehow.
To change all the profiles in one shot it's quite easy from the command line using sed (under ~/.local/share/remmina), if you need a quick workaround and don't know how to do let me know.
-
The files were in ~/.remmina @box293 This is because you are an old remmina supporter ;-) (thanks)
@kevin201 it works for me, but I use keychain at logon time that automatically add my ssk keys. With gnome_keyring should be the same, but must be configured to save ssh keys as well at logon time. Sorry for the confusion.
It's still not clear for me as well how to use the auto method. I think that I've started to implement it in Remmina for the dual factor authentication, but I don't remember.
Still investiagting
-
I remember now and it should work correcthly.
ssh_userauth_publickey_auto() uses the SSH_AGENT and you pass to it the username and the passphrase (in the password field) ssh_userauth_agent() uses the SSH_AGENT as well but you don't need to pass the passphrase (only the username).
So can you confirm that entering the passphrase in the password field with the auto method works?
I should find the time to update the user doc, but it's not really easy to find free time :-\
https://github.com/FreeRDP/Remmina/wiki/Remmina-User's-guide
I hope you'll post here when the PPA is updated. I switched back to the ubuntu packaged version due to this issue. edit: I am reminded that that version has other bugs. Found the remmina-next-daily ppa which seems like it should have the fix based on build date, but it doesn't work for me. But it does work with "public key (automatic)" instead of "SSH agent (automatic)". edit again: looking more closely at the daily ppa it seems it got built for 16.04 but not yet for 17.04, so the build I am testing doesn't have the fix.
-
Please help me to understand the problem, because I'm quite lost
I've just tested the last commit in our main branch (named 'next' https://github.com/FreeRDP/Remmina/commit/202d17f5bec8d8aac386b647bf5f4be3c2ab0ff7 ) and it works.
My config:
Protocol: SSH Server: barce (my final destination) 192.168.122.167:22 Tunnel: rex (my stepping stone) 192.168.0.28:22 Authentication Type: SSH Agent
I've an SSH Agent running through keychain.
The Public Key auto method means:
The function ssh_userauth_autopubkey() does this using the available keys in "~/.ssh/". The return values are the following:
SSH_AUTH_ERROR: some serious error happened during authentication SSH_AUTH_DENIED: no key matched SSH_AUTH_SUCCESS: you are now authenticated SSH_AUTH_PARTIAL: some key matched but you still have to provide an other mean of authentication (like a password).The ssh_userauth_publickey_auto() function also tries to authenticate using the SSH agent, if you have one running, or the "none" method otherwise.
Ref: ssh_userauth_publickey_auto
For the pure ssh_agent implementation, the one I've just tested successfully, as far as I understand from the documentation, needs a local ssh agent running, it's not Remmina (read libssh in this case) that will execute one, nor Remmina will catch if the agent needs the authentication.
What am I missing? Looking at the old code I don't see anything that could start the agent automatically.
If the 'next' branch works, on the other hand, I still need some time to publish a new release, because I'm working on a couple of things that have to be done.
As a temporary workaround, if you have one of the last commits, you should have an interface like this:
It's to set an ssh tunnel in the prior command, i.e. I've added this in a script:
ssh -N -L 2222:192.168.122.167:22 -i /home/myusername/.ssh/id_rsa thatusername@192.168.100.28 &
Plus other commands to log the IP of the tunnel.
Than in the "post command" I've an other script path that kill the ssh_agent at the end of the connection.
The prior and post commands now supports niddles (%u %U %h %t) and command arguments, so I think you have several means to temporary workaround this issue.
But please, help me to identify the exact problem if it's still there and sorry...
-
TL;DR To resume, I've just saw a couple of comments.
This issue is solved, but unlucky, I cannot release a new version right now.
On Arch you can install the remmina-git AUR package, the package name include the version number, but it's worng, the AUR is always built from the last commit, so go ahead with it.
Ubuntu has the remmina-next-daily , follow this https://github.com/FreeRDP/Remmina/wiki/Testing-under-Ubuntu-with-the-remmina-next-daily-PPA
If with the 2 repositories above you still have issues, read my previous comment and help me :-)
Thanks
-
Just tested with RDP and it works. This is my profile:
$ cat ~/.local/share/remmina/1513464259523.remmina [remmina] sound=off sharefolder= name=RDP SSH Tunnel test cert_ignore=0 console=0 ssh_enabled=1 exec= clientname= loadbalanceinfo= server=foo.windowssrv.com:12345 colordepth=16 ssh_auth=2 postcommand= group=TESTING sharesmartcard=0 quality=1 username=mywindowsusername ssh_charset= ssh_loopback=0 ssh_username=mysshtunnelusername gateway_password= gateway_server= gateway_username= microphone=0 execpath= resolution_width= gateway_usage=0 disableautoreconnect=0 password=. resolution_height= security= domain= disablepasswordstoring=0 precommand= ssh_server=192.168.100.28:22 protocol=RDP shareprinter=0 gateway_domain= disableclipboard=0 ssh_privatekey= scale=2 window_maximize=0 window_height=1041 dynamic_resolution_height=1011 window_width=1920 dynamic_resolution_width=1873 viewmode=1ssh_auth = 2means SSH Agent as per this array:/* Array of key/value pairs for ssh auth type*/ static gpointer ssh_auth[] = { "0", N_("Password"), "1", N_("SSH identity file"), "2", N_("SSH agent"), "3", N_("Public key (automatic)"), "4", N_("Kerberos (GSSAPI)"), NULL };Can you share your profile as well?
-
Created by: mattpepin
Here's my profile, with sensitive info edited. I get the error message I mentioned above. It still does not work if I SSH from the command line before to unlock my key. It works if I use Public key (automatic), but I don't want Remmina to manage my keys. remmina --version gives me:
Running under Gnome Shell version 3.26.2 Remmina - Version 1.2.0-rcgit-24 (git 202d17f5)
[remmina] sound=off sharefolder= microphone=0 name=Test RDP proxy= cert_ignore=0 ssh_enabled=1 showcursor=0 exec= clientname= console=0 colordepth=16 server=test-pc keyboard_grab=1 loadbalanceinfo= ssh_auth=2 scale=1 aspectscale=0 ssh_charset= quality=2 disableencryption=0 ssh_loopback=0 group=TESTING ssh_username=server password=test username=test hscale=0 disablepasswordstoring=0 gateway_server= window_maximize=1 viewmode=1 gateway_usage=0 disableautoreconnect=0 viewonly=0 postcommand= resolution= security= window_height=704 keymap= domain= precommand= window_width=1364 sharesmartcard=0 ssh_server=testing.duckdns.org:2642 protocol=RDP shareprinter=0 disableserverinput=0 disableclipboard=0 ssh_privatekey= vscale=0 execpath=
-
My profiles are in ~/.remmina, not in ~/.local/share/remmina. I guess it's distro specific? I used the path shown in the status bar.
It's not distro specific, ~/.remmina comes from an old version of remmina. The new versions of Remmina, new as about year old maximum, copies automatically the profiles from ~/.remmina to ~/.local/share/remmina. Can you check if you still have an old version installed somehow? The problem may lie in a melange of remmina versions.
-
Created by: mattpepin
You were right, my profiles were also copied to .local/share/remmina, but for some reason, it still used the old ones. I tried removing everything from both locations and start from scratch, but the issue persists. I can also confirm I only have 1 remmina binary (which is in /usr/bin).
-
Please TEST. Hopefully I've just pushed a fix for this. As per libssh documentation we SHOULD not send the username to the ssh_agent. In some cases, I think, when the local and remote users are the same, or when in the ~/.ssh/config file the user name is set, the ssh_agent was working (I was in these 2 cases).
I'm quite sure I've broken something else, so please test.
Thank you for our patience!!!
-
Created by: mattpepin
I just recompiled latest git (git 055e33b3), and I still have the issue.
-
I'm short of ideas. https://blog.codefront.net/2007/02/28/debugging-ssh-public-key-authentication-problems/
On Remmina you set the ssh verbosity in the general preferences.
The sshd test may really help out and the authlog as well.
-
Created by: mattpepin
Here's the end of the debug log:
[SSH] ssh_agent_get_ident_count: Answer type: 12, expected answer: 12 [SSH] ssh_agent_get_ident_count: Agent count: 2 [SSH] pki_import_pubkey_buffer: Invalid public key length [SSH] ssh_socket_unbuffered_write: Enabling POLLOUT for socket [SSH] packet_send2: packet: wrote [len=28,padding=11,comp=16,payload=16]
-
My private key is 4096 bytes long, not 2048. Maybe that's the issue?
@mattpepin Looks like to me that you have one of the following issue:
- An ssh agent running with an old (2048) key loaded Check you don't have any other ssh-agent (keychain, gnome-keyring, gpg-agent, ???)
- Your 2048 key is sent as the first key and when it fails libssh doesn't try the second one libssh, as far as I've understood, should send one key after an other, till it gets a positive answer or till there are not any new keys. If this is the case, I think it's more a libssh issue. Try to unload this key and try again, as you have an older version of libssh, I don't expect they will fix this behaviour.
- A libssh bug It could be, but I don't know how we can debug this, except writing a libssh ssh client for debugging purpose.
I hope in the 1st case honesty, I'm honestly puzzled
-
I just tried the Ubuntu next-daily version, but I still get this message: kex error : no match for method server host key algo: server [ssh-ed25519], client [ecdsa-sha2-nistp256,ssh-rsa,ssh-dss] Do I have to compile the git to have a more up to date version?
@Arkem5 Is this error related to the SSH debug messages you have shared?
In this case you should be able to workaround it setting the Kex in the ~/.ssh/config file
KexAlgorithms ssh-ed25519Let me know if it helps.
If you have the last remmina-daily, I've added some new feature in the SSH protocol (not in the agent, but in the protocol itself). Would you mind trying it specifying the correct algorithms? If it works I could add that options in the ssh tunnel tab
-
Created by: mattpepin
It turns out it does have a link with my private keys. If I only leave my id_rsa and id_rsa.pub in my ~/.ssh folder, it works! I iterated over the keys I had, and I found out that the culprit was id_ecdsa and id_ecdsa.pub. As soon as I remove this key, it works. I did not even use it anymore, as I moved to ed25519. The issue is resolved, but I still think it's a bug because the login should have still worked.
-
@mattpepin this is because of #1187 (closed) I don't know how I can make everybody happy :-P I'll take a look if I can improve this
-
@Arkem5
I've tested an ed25512 key and it works
- I've created and installed the key
$ ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519 -C "Remmina - test ed25519" $ ssh-copy-id -i .ssh/id_ed25519 tmow@rex-
Tested by hand (works)
-
Created the Remmina profile (Here after the relevant options)
[remmina] ssh_auth=2 ssh_privatekey=/home/tmow/.ssh/id_ed25519 ssh_color_scheme=0 ssh_loopback=0 name=rex ed25519 ssh_username=tmow protocol=SSH sshlogenabled=0 ssh_enabled=0 ssh_stricthostkeycheck=0 disablepasswordstoring=0 server=rex- Removed unneeded ssh keys:
ssh-add -l ssh-add -d /path/to/some_key- Test Remmina
Works!
I'm on Arch, so I've only the last version of almost everything.
-
It turns out it does have a link with my private keys. If I only leave my id_rsa and id_rsa.pub in my ~/.ssh folder, it works! I iterated over the keys I had, and I found out that the culprit was id_ecdsa and id_ecdsa.pub. As soon as I remove this key, it works. I did not even use it anymore, as I moved to ed25519. The issue is resolved, but I still think it's a bug because the login should have still worked.
@mattpepin I'm going to push a commit that should fix this bad behaviour, tell me what do you think about the logic
- Remmina first searches for identities in the ~/.ssh folder in this order
.ssh/id_ed25519 .ssh/id_rsa .ssh/id_dsa .ssh/identityThe first identity file (private key) found is the only identity that will be used (except if point 2). 2. Identity file explicitly set in the profile settings. If the user has set in the profile option an identity file, that identity file will be used for any kind of public key authentication (ssh-agent, automatic, etc)
In this way all the cases should be covered.
@ssten I'd love to have also your opinion on this whole thread, do you mind? Thanks
-
Created by: ssten
Accordingly with (#1374 (closed) ) ~/.ssh/id_dsa may be used, but in such case user must be warned about usage of obsolete algorythm. ~/.ssh/identity is the thing I've just heard, but don't used and incompletely understand.
Commonly, for my experience, attepmts to guess proper private key may provide uclear to understand and unpleasant surprises. Documented list of checked private key files is a good and right thing. But it is not complete. I suggest to check number of found standard private keys. And, if find more than one, autoselect mode should fail, notifying user, that he must select exact one.
-
I've just commit something that everybody should like.
Soon I'll submit a pull request and merge it in the main branch.
I've added the possibility to set
username@server:portin the custom field in the SSH tunnel tab. Only for SSH and SFTP obviously.I still have to perform some tests.
