PUTTY and Tumbleweed

Hello.
My putty not work after dup to VERSION_ID=“20180425” of the Tumbleweed now.
while a connection I see a window with text: Disconnected: No supported authentication methods available (server sent: publickey,keyboard-interactive)

but I can connect by ssh with my key to any servers.

nick@STRELKA:~> ssh 172.25.0.222
Last login: Sun Apr 29 16:11:05 2018 from 172.25.0.225
Have a lot of fun…
nick@172.25.0.222~> exit

nick@STRELKA:~> putty -log log -ssh -i .ssh/id_rsa 172.25.0.222 ; cat log
=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2018.04.29 16:50:57 =~=~=~=~=~=~=~=~=~=~=~=
Unable to use key file “.ssh/id_rsa” (OpenSSH SSH-2 private key (old PEM format))
Using username “nick”.
nick@STRELKA:~> putty -log log -ssh 172.25.0.222 ; cat log
=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2018.04.29 16:51:26 =~=~=~=~=~=~=~=~=~=~=~=
Using username “nick”.

Please, help.
Nick

Are you trying to use a DSA key for authentication? As far as I know, recent “openssh” releases have deprecated DSA keys.

I’m assuming that this is PuTTY from Windows (there’s also a linux port of PuTTY).

I’ve just tested this.

PuTTY running on Windows 7. I used a DSA key. I was able to login to openSUSE Leap 42.3. But I got an authentication failure when I tried to login to openSUSE Tumbleweed (snapshot 20180406).

I then added an RSA key to PuTTY, and was able to login without a problem.

This was a relatively recent change to Tumbleweed – probably within the last 2 months. You can maybe check history to see when “openssh” was last updated.

Obviously, you will need to create a new key for PuTTY, using an authentication method other than DSA.

Thanks, but I use rsa. Ok, I’ve made a new keys, but result is the same. I’ve tryed with different servers, it was Centos7, Tumbleweed. The client is a last Tumbleweed. I’ve not made any keys by the putty, it has got id-rsa key file from my .ssh dir. But after last update of Tumbleweed the putty is not connect. It was worked yesterday. The problem started after the update. Please check my example, the ssh is work fine now. I will check an update history…
I think, the putty is nonchanged… Yet, I’ve got and successfully compiled last putty from it site, the result is the same. :frowning:

My keys are all originally openssh keys, imported to PuTTY. So that’s not the issue.

Check permissions very carefully. And check “sshd_config” on Tumbleweed. In my experience, “sshd” is fussy about permissions. The “.ssh” directory must be owned by either the user (i.e. you) or by root, and must not be group writable or other writable. And the authentication config in “sshd_config” must allow the kind of authentication that you are using.

There’s a log option in Putty. Maybe you can use that to get a better idea on what is going wrong.

Thank you very much!

SOLVED! The problem is a changing of /etc/X11/xinit/xinitrc file. Some update rewrite the file to new file with commented

if test -S “$SSH_AUTH_SOCK” -a -x “$SSH_ASKPASS”; then
ssh-add < /dev/null
fi

strings.

The update save xinitrc.rpmsave file with uncommented important strings.

Nick

2020 sep 04

Tumbleweed has “lost” a SSH_ASKPASS variable.

test -S "$SSH_AUTH_SOCK" -a -x "$SSH_ASKPASS" will be ‘false’ always now. ($SSH_ASKPASS is not defined)

so, ‘ssh-add’ command not launch.

I recommend to correct part of xinitrc file to this view:

if test -S “$SSH_AUTH_SOCK”; then
ssh-add < /dev/null
fi

What you think about?

Good. It should never have been defined in the first place.

Looking on Leap 15.2, I see

SSH_ASKPASS=/usr/lib/ssh/ssh-askpass

But I am using KDE, so I want to use “ksshaskpass” instead of the one that is defined. So I have to override that anyway.

I did test this a few days ago. Running “ssh-add key < /dev/null” currently brings up “ksshaskpass” when I am running KDE, but brings up the “ssh-askpass” built into openssh when I am not in KDE. A predefined SSH_ASKPASS is not needed unless you want to force a particular version.

test -S "$SSH_AUTH_SOCK" -a -x "$SSH_ASKPASS" will be ‘false’ always now. ($SSH_ASKPASS is not defined)

so, ‘ssh-add’ command not launch.

You can define SSH_ASKPASS in your shell startup files or in your desktop startup files (if your desktop supports that).

I recommend to correct part of xinitrc file to this view:

if test -S “$SSH_AUTH_SOCK”; then
ssh-add < /dev/null
fi

What you think about?

Terrible idea.

I launch “ssh-add” when I am ready. I don’t want it as part of desktop startup. But we all have different preferences, and that’s why you can configure such things yourself.

Does such a file exist? It’s absent on Tumbleweed.

root@BELKA:~> echo $SSH_ASKPASS

root@BELKA:~> ls -la /usr/lib/ssh/ssh-askpass
ls: cannot access ‘/usr/lib/ssh/ssh-askpass’: No such file or directory

In Tumbleweed, that is now in “/usr/libexec/ssh” (very recently moved).

The story started when I’ve lost putty functionality after Tumbleweed upgrade.
The SSH_ASKPASS variable still undefined.
Yes, I use KDE. ksshaskpass is installed…
But I can’t login to remote hosts by ssh key. It work after manually ssh-add command.
What changed after Tumbleweed update and what is better way to use the putty with ssh keys from KDE?

Perhaps putty needs to be updated to also look at “/usr/libexec/ssh”.

You can maybe try making “/usr/lib/ssh” a symbolic link to “/usr/libexec/ssh” and see if that fixes your problem. And if that does fix it, you should file a bug report about Putty needing to be updated to use “libexec”.

I guess I have always used “ssh-add” to add the keys that I use with Putty. And I don’t currently have Putty installed.

No, that not fix the problem.
root@BELKA:~> l /usr/lib/ssh
lrwxrwxrwx 1 root root 16 Sep 8 17:18 /usr/lib/ssh -> /usr/libexec/ssh/

Of course, I can start “ssh-add” for work. But I haven’t done that before.

I will maybe install Putty in Tumbleweed, and experiment with it. But I’ve never done it that way. I have used Putty in openSUSE, but always using “ssh-add” for the keys. I guess it won’t hurt for me to experiment.

Note, Putty use own pageant, but it can’t ask a key wo “ssh-add”.
pageant: listing keys: Did not receive an SSH-1 key list from agent

Thank you for help.

I ran “pageant” at session startup. If I then run

pageant -a keyname.ppk

it adds the key.

To run pageant at session startup, I used (in a shell script):

eval `pageant -X`

I guess I don’t know how people use putty in linux.