Sftp connection failed kex error

«kex error» since upgrade of SSH daemon #31

Since our server have upgraded the OpenSSH daemon, the NPPFTP plugin cant connect any more :

It seems that NppFtp with LibSSH 0.6.5 is not compatible with the last openssh.

The text was updated successfully, but these errors were encountered:

What is the OpenSSH version and what is the environment it is using?

OpenSSH version :
SSH-2.0-OpenSSH_6.7 PKIX

Env :
Suse Linux Enterprise Server 11, level 2 3.0.101-0.7.23-xen #1 SMP Tue Aug 19 15:56:19 UTC 2014 (26d8f4e) x86_64 x86_64 x86_64 GNU/Linux

I got a similar complaint from a co-worker (so I don’t have the exact message, sorry), our SSH config follows recommendations from here.
We have OpenSSH 5.9, relevant piece of sshd config:

@jaymore, can you see something comparable in your /etc/ssh/sshd_config ?

It looks like diffie-hellman-group-exchange-sha256 is not supported even in the latest version of libssh (0.7.0), a patch was proposed in January but did not seem to have been merged yet as it is pending review. The only supported algorithms right now seem to be:

• diffie-hellman-group1-sha1
• diffie-hellman-group14-sha1
• ecdh-sha2-nistp256
• curve25519-sha256@libssh.org

@Mrten: looks like curve25519-sha256@libssh.org is the best choice as per the linked article and is supported, so that looks like your best bet.

Alas, OpenSSH 5.9 (from ubuntu precise) does not support that algorithm yet 🙂 I’ll add diffie-hellman-group14-sha1 for my coworker, thank you for the link to the libssh docs, but my comment was mainly meant to present an avenue to pursue.

@Mrten : sorry, i do not have read access to /etc/ssh/sshd_config on my server (I dont have a root access).

So I’m now sitting next to someone with NppFTP on a windows laptop, and after enabling diffie-hellman-group14-sha1 on the ssh server the exchange now fails on the same as above: [SFTP] Connection failed : kex error : no match for method mac algo client->server: server [hmac-sha2-512,hmac-sha2-256,hmac-ripemd160], client [hmac-sha1] .So I’ve enabled the mac and everything is peachy.

Have you got a timeframe for libssh 0.7.0? I understand sha256 is supported there.

@Mrten: I was unable to get it compiling, I use the same setup used for wkhtmltopdf for the dependent libs. Will have to try again as it looks like this issue will be solved by the upgrade.

Please let me know if it works for you with v0.26.4.

Remove the just-added hmac-sha1 from the config and it seems to continue working. Thanks!

As an issue for users of notepad++ that are trying to use ftp plugin to connect to the ssh or sftp from a recently updated debian server, just add «hmac-sha1» to the line of /etc/ssh/sshd_config . The issue here is that notepad’s++ ftp plugin uses hmac-sha1 to encode the ssh connection but latest ssh updates are working with hmac-sha2 only.

Line 89 of sshd_config (corrected):
MACs hmac-sha2-512,hmac-sha2-256,hmac-ripemd160,hmac-sha1

In my case the update worked perfectly.

I am having this issue can anyone help me.. Thanks !
kex error : no match for method mac algo client->server: server [hmac-md5,hmac-sha1-96,hmac-md5-96], client [hmac-sha1,hmac-sha2-256,hmac-sha2-512]

i updated Npp to 0.26.4

Looks like your server has not been updated as it uses too old and insecure algo support.

I understand it using hmac-md5-96 Is there a way to connect to that server/ i am not the admin to that server i just need to connect to that and work along, do we have older version of Npp that use same algorithms as server? Thanks for quick reply

I’m getting the below error while use the kex exchange in the SSH2.pm file.

20170706 15:26:01 Command «/apps/tfs/automation/tfs_exec.sh ./get_dli_tfs_files BMO» on host XXXXX failed execution by the Autosys ssh wrapper.
Return code from the command was 255.

msg: login to transfer server — ssh
msg: list files from remote server

2017-07-06 15:26:01 Could not get ls of /Out/bmo
Exit code=255
STDOUT=
STDERR=No kex algorithm at /usr/local/share/perl5/Net/SSH/Perl/SSH2.pm line 92

Below is the SSH2.pm files entry at 92 line.

my $kex = Net::SSH::Perl::Kex->new($ssh);
$kex->exchange;

can someone please help me with this error.

Источник

SFTP not working (SFTPSession: Failed to connect ‘kex error : . ) #751

Hi,
I’m trying to connect inside Kodi (Videos > Files > Add Videos > Browse > Add network location > Protocol: Secure shell (SSH/SFTP)) to a server using SFTP. But his doesn’t work (HTTPS is working).

On my raspberry pi running xbian (Kodi 14.2 Git:Unknown (Compiled: May 7 2015))

Here are the corresponding lines from kodi.log:

In IRC of whatbox, they said it’s a problem with the older version of SSH in Kodi/XBMC. But I’m not sure how to proceed and upgrade that one.

Can someone clarify this, please? And does there is a workaround to solve this problem? Is it a good idea to upgrade OpenSSH manually?

Thanks for any help.

Here is the corresponding topic in the xbian forum: http://forum.xbian.org/thread-3063.html

The text was updated successfully, but these errors were encountered:

I tested it by connecting to my homeserver (running debian wheezy). Had no problem, can play videos without any issues.

I did some more research on this topic.

I found a post in a forum that seems related to this problem. Here someone suggested to add:

EDIT: Bad Idea. Don’t do this. I can’t connect using SSH anymore.

I couldn’t test it yet. But I will reply here, if I checked it. But the error message sounds like the used algorithm isn’t available/activated in this SSH version in xbian.

But I don’t know enough about key exchange algorithms to know if this addition will make it is insecure.

And this issue from OpenELEC seems also related and it was solved by upgrading libssh:
OpenELEC/OpenELEC.tv#3587

It seems that OpenELEC also upgraded to update to openssh-6.8p1 (and to openssh-6.9p1 in Beta 6.0). (Source: http://openelec.tv/news/22-releases/)

But I don’t know if I could connect with SFTP in OpenELEC and I don’t want to switch.

No solution so far. Editing /etc/ssh/sshd_config doesn’t help. No SSH login possible afterwords — had to restore a snapshot. I edited the post above.

How are the chances to use a more recent version of OpenSSH? And if someone knows how to upgrade to the current one, please tell me that I can test it.

How are the chances to use a more recent version of OpenSSH?

1. Upgrade your RPi manually to Jessie (I already did this for testing, no problem) .

OK, I will try this in the next days.

I just tested to use sftp on the command line and it works. That means the openssh version shouldn’t be the problem. But how is this possible? Why is it not working within Kodi?

is this an issue ?

I have just set this up and I am experiencing this issue (SFTP to a Arch server)

first of all check, that your ssh is something of actual version.

Any news on this issue at all?
I’ve had the exact same problem for months now. The server is an Debian 8.2 jessie server-edition, with multiple clients running on Windows, Debian, OpenELEC and Android.
Just tested Kodi 16 beta 3 and the issue still exists.

My setup works perfectly with Kodi 14.2 , but any newer version won’t work at all.
I just don’t see any real alternatives at all. FTP unsecure, SMB / NFS local network only.

As far as I can see, this is a Kodi problem, not SSH server problem. diffie-hellman-group1-sha1 is weak and within theoretical range of the so-called Logjam attack , so why has Kodi started using it then? Unsupported or disabled on most up-to-date servers.

SSH server, up to date (no newer version available for Debian jessie at least)

@JanPetterMG
I checked it again in my environment with 16 b3, server Debian Jessie now, works perfectly.

Got this in my Kodi logs:

I noticed the second line, this is missing in your logs.
So my question: do you try to login via password or key — I’m using password, it is enabled here in sshd because I need this for using X2GO

@mkreisl I’m using password.
I’ve tested 16 b3 in Windows 10 only, 15 has been tested on most devices, but didn’t work.
I’m going to test 16 b3 on other devices too, because this is strange.

So, it seems to be a general Kodi issue, not XBian.
Please open a Ticket there http://trac.kodi.tv/

this even is not kodi, that is certificates / configuration at the server side. .
I remember that from past, unfortunately do not remember more.

@mk01 Yes, this could be. But unfortunately you do not remember more. My server configuration is default, never changed anything (as far as I remember)

The error
«Failed to connect ‘kex error : did not find one of algos diffie-hellman-group1-sha1 in list . »
are related to an outdated version of libssh, acording to:
OpenELEC/OpenELEC.tv#3587

I don’t remember more in the sense of specific Ciphers which has been disabled by default (in what ssh version). After little browsing:

easiest way is to put back those disabled by default now (by editing /etc/ssh/sshd_config) and putting

if there is no control over sshd, then perhaps by putting similar line — but with the second group
of cipher names into /etc/ssh/ssh_config. or creating

/.ssh/config with specific host and cipher
config like this:

this should take effect for sftp/ssh sessions opened from within xbmc too.

anyhow, the whole problem can be the other way around — meaning that server is forcing one of the older ciphers/keyexch algorithms and local system (kodi/ssh/xbian/whatever) is refusing to use it for communication.

reverting to the short copy&paste log above, client logs kex error what is keyexchange alg problem. in that specific case would be needed:

copy the list, remove from it the one obsolete, edit ssh_config by putting

Источник

FileZilla Forums

Welcome to the official discussion forums for FileZilla

[SOLVED] SFTP — Could not connect to the server — error: Hm, kex protocol error: type 30 seq 1 [preauth]

[SOLVED] SFTP — Could not connect to the server — error: Hm, kex protocol error: type 30 seq 1 [preauth]

#1 Post by murkydeeds » 2015-08-09 07:47

For anyone wondering, this is fixed in FileZilla 3.13.0-rc2.

I’ve been using FileZilla to mostly connect to the various SFTP servers. Recently I updated OpenSSH on my Gentoo box and PuTTY and SFTP could not connect any more.

The error I see in the system log is:

(IP address is my client’s IP)

I found this blogpost explaining (sort of) what’s happening. The proposed solution worked for me in PuTTY — i.e. I changed the order of key exchange algorithms.

I tried to search around to see if FileZilla offers similar setting but I was unable to find anything.

Does FileZilla currently allow for changing these settings?

Thank you!
Murky Deeds

OpenSSH_6.9p1-hpn14v5, OpenSSL 1.0.1p 9 Jul 2015
FileZilla for Windows: 3.12.0.2 64bit
Also tried nightly: 3.13.0-rc1 64bit

Re: SFTP — Could not connect to the server — error: Hm, kex protocol error: type 30 seq 1 [preauth]

#2 Post by botg » 2015-08-09 18:12

Re: SFTP — Could not connect to the server — error: Hm, kex protocol error: type 30 seq 1 [preauth]

#3 Post by murkydeeds » 2015-08-09 18:26

thank you for the quick reply. Currently I am using Filezilla Portable by PortableApps, but I assume it applies to the standalone or installed version as well. I am not using FileZilla together with PuTTY though.

Is there a FileZilla config file in which I can change this option?

Thank you very much.

Re: SFTP — Could not connect to the server — error: Hm, kex protocol error: type 30 seq 1 [preauth]

#4 Post by botg » 2015-08-09 19:01

Re: SFTP — Could not connect to the server — error: Hm, kex protocol error: type 30 seq 1 [preauth]

#5 Post by murkydeeds » 2015-08-09 21:26

I apologize, but I don’t know how to do that. Would you be so kind as to point me in the right direction?

I will try with this version:
http://sourceforge.net/projects/filezil . oad?nowrap
so it’s not interfering with the PortableApps packaging.

How can I use PuTTY to change the SFTP settings?

Also, is it possible that this will be a general problem in the upcoming months, when other Linux distros start to deploy OpenSSH version 6.9p1 or newer?

:: EDIT ::
I just tried OS X and the same thing happens with FileZilla there.

:: EDIT #2 ::
Just to be on the safe side, I tried fresh install of Fedora 22, updated the packages using ‘dnf update’ command (so I would get OpenSSH server 6.9p1), and the problem seems to be identical — when I tried to connect to that machine with FileZilla.
Fedora 22 amd64
OpenSSH_6.9p1, OpenSSL 1.0.1k-fips 8 Jan 2015

So it seems like an issue in psftp itself, regardless of the OS.

Источник

NPPFTP cannot connect and upgrade alters error message to be less informative #141

Description of the Issue

I am using NPPFTP 0.26.9. Prior to that I was using the previous version. I am having an issue connecting to a linux server. The previous message gave me a kex exchange error saying the client (me) was using sha1 and the server only accepts sha2. Now the message is
[SFTP] Error during authentication: Access denied. Authentication that can continue: publickey
Unable to connect

I updated in hopes of gathering the appropriate algorithms. I will say WinSCP works just fine as does SSH to that server. Just NPPFTP is having issues. Also I upgraded to NPP 7.3.3 with the same result.

###Connection Config
SFTP
port 22
username
timeout 0 (it starts at 30 but alters itself to be 0 I’ve noticed)
try private key
(key is OpenSSH PPK, same key used for SSH and WinSCP)
The rest is default

Expected Behavior

Actual Behavior

Debug Information

Notepad++ v7.3.2 (32-bit)
Build time : Feb 12 2017 — 23:15:39
Path : C:Program Files (x86)Notepad++notepad++.exe
Admin mode : OFF
Local Conf mode : OFF
OS : Windows 7 (64-bit)
Plugins : mimeTools.dll NppConverter.dll nppcrypt.dll NppExport.dll NppFTP.dll PluginManager.dll

NPPFTP 0.26.9
SFTP
private keyfile

The text was updated successfully, but these errors were encountered:

Источник

[РЕШЕНО] Openssh. Проблема с внешним подключением к серверу

# 7 лет, 2 месяца назад (отредактировано 7 лет, 2 месяца назад) Добрый день!
Поднял Openssh согласно wiki.
Проблема в том, что с самого арча к серверу подключаюсь:

При попытке подключиться из офисной сети через Putty с Windows машины даже не появляется приглашение ввода имени пользователя/пароля.
Пинги до арча с компа ходят.

iptables не запущен, правил нет.

В какую сторону смотреть?
Конфигурация sshd:

В настройках putty указываете явно, что надо использовать имя пользователя bsscp (AllowUsers bsscp)?

С windows-машины попробуйте из командной оболочки зайти с помощью telnet на 22 порт. Если все хорошо, должно выглядеть как-то так:

$ telnet 192.168.1.1 22
Trying 192.168.1.1.
Connected to 192.168.1.1.
Escape character is ‘^]’.
SSH-2.0-OpenSSH_6.9

После этого можно будет дальше разбираться

kurych
В настройках putty указываете явно, что надо использовать имя пользователя bsscp (AllowUsers bsscp)?

С windows-машины попробуйте из командной оболочки зайти с помощью telnet на 22 порт. Если все хорошо, должно выглядеть как-то так:

$ telnet 192.168.1.1 22
Trying 192.168.1.1.
Connected to 192.168.1.1.
Escape character is ‘^]’.
SSH-2.0-OpenSSH_6.9

После этого можно будет дальше разбираться

Тогда попробуйте в putty использовать не сохраненную сессию, а новую, без всяких настроек. То есть, просто введите в поле «Host name (or IP address)» нужный адрес и попробуйте соединиться.
Если получится — с настройками сессии перемудрили. Если нет, то надо смотреть логи. На стороне сервера
на стороне putty включить логгирование в меню «Session-Logging» Добрый день!
Решил проблему.

Поставил Openssh на Win машину. При попытке подключения выдало «no kex alg». Goggle выдал решение в виде добавить в sshd.conf строчку:

© 2006-2022, Русскоязычное сообщество Arch Linux.
Название и логотип Arch Linux ™ являются признанными торговыми марками.
Linux ® — зарегистрированная торговая марка Linus Torvalds и LMI.

Источник

no kex alg

If you run ancient operating system with an old version of SSH client then you are going to hit this “No Kex Alg” problem soon.

For example Solaris 9

So what a hell is it? What’s causing it? Well, modern operating system like Debian Jessie are packaged with OpenSSH 6.7 or newer – and Openssh 6.7 disables a number of ciphers, as per changelog http://www.openssh.com/txt/release-6.7 As Russel rightly pointed out in comments section below ‘”kex” is “key exchange”.x

So it’s time to upgrade your client! However, if for some bizarre reasons those pesky sysadmins are refusing to upgrade client software then that leaves you with two options:

• if you have physical access to client simply spill coffee or some other beverage on it (alright, just joking)

• or edit /etc/ssh/sshd_config on the server, append the following line and restart sshd daemon

Now your old client should be able to connect to server plus you have successfully created security vulnerability on your machine. How exciting!

If you’re still dying to know what mechanisms your system supports run:

I know more about ssh ciphers, macs, kex now that I ever wanted to know.

7 Responses to “no kex alg”

Ha ha… yet I laugh with real joy.. since I have *finally* jailbroken my iPad and have just logged into it from one of my Linux boxes …! I got the Cydia stuff running on the iPad, and first install was OpenSSH package, but coming from an old Windows-XP box, with “ssh”, all I could get was this goofy “no kex alg” message.. – hmmm now to decode the linux-crypto-msg…? “no” is easy, probably means “no, you dumbguy!”… “kex” sounded like an ancient breakfast cereal, but “alg” – now that’s gotta be short for “algorithm” (finance hackers use “algo”, so pretty close, eh? .. ) but “kex” had me stumped. Now what could that be??
Of course, my SSH client on the winbox is ancient (and the iPad is Gen-0, from the days when Steve Jobs was still on earth), so probably it was an unsupported algo which my ancient winbox ssh used, but now is compromised and easy to hack? Am I getting a bit warm here?
Anyway, your webpage was really helpful. Thanx for taking the time to publish it.
I suppose a modern version of PuTTY might work? What I find really impressive, is that I can login to my old iPad version 1, and from a terminal session window on a CentOS Linux box, enter “ls -l –col”, and get a directory list with colour codings…
… Ok, I just tried it.
My Winbox “ssh” returns “no kex alg”, but old PuTTY with Blowfish and triple DES seems to work.
THere. I can login to the *unix O/S running on my iPad, from my Windows-XP session, using an old version of PuTTY.
Just one dumb question: What the heck does “Kex” mean?
(I suppose I will have to break down, and actually look at the OpenSSH release notes, eh? )
– Rus

Источник

Kex algorithm diffie-hellman-group16-sha512 #616

vorband commented Nov 14, 2018

Please add support for kex algorithm diffie-hellman-group16-sha512.
I happen to be blocked out of a server that sets the following ciphers in the sshd_config:

Connecting gives me the following error:

A fix is greatly appreciated.

The text was updated successfully, but these errors were encountered:

I’m glad to tell you that next release should support it. I can send you invite to TF version, so you can test it.

with libssh-0.8.5 got following error:

We have released v12.4 with libssh-0.8.6. Is it better for you? Can you please check it?

vorband commented Jan 11, 2019

hi @yury, I am still getting kex error : no match for method mac algo client->server: server [hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com], client [hmac-sha2-256,hmac-sha2-512,hmac-sha1]

vorband commented Jan 11, 2019

Don‘t worry, I have a workaround.

Is there any update on when this will be released? I have a couple servers that I need to connect to but I don’t have full control over.

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

Sorry, no news yet. Need to report to libssh team.

I got good news!

There is already PR (actually MR) for that.

Hope it will make in feb release.

Another update. PR just landed into master. So it will be in February release.

Please reopen if it is not working for you!

Yury, this is working beautiful in my usecase. Thank you for getting this working!

vorband commented Mar 7, 2019

Same here. Thank you!

All credits should go to Dirkjan Bussink. He is the one who actually implemented that in libssh.

Actually, I’m still seeing this issue on one of my docker containers with 12.7:

blink> ssh -l root hassio.local

kex error : no match for method mac algo client->server: server [hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com], client [hmac-sha2-256,hmac-sha2-512,hmac-sha1]
blink> ssh -v -l root hassio.local
socket_callback_connected: Socket connection callback: 1 (0)
ssh_client_connection_callback: SSH server banner: SSH-2.0-OpenSSH_7.7
ssh_analyze_banner: Analyzing banner: SSH-2.0-OpenSSH_7.7
ssh_analyze_banner: We are talking to an OpenSSH client version: 7.7 (70700)
ssh_known_hosts_read_entries: Failed to open the known_hosts file ‘/etc/ssh/ssh_known_hosts’: No such file or directory
ssh_kex_select_methods: kex error : no match for method mac algo client->server: server [hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com], client [hmac-sha2-256,hmac-sha2-512,hmac-sha1]

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

You should be able to recreate this by setting:

Источник

«kex error» since upgrade of SSH daemon #31

Since our server have upgraded the OpenSSH daemon, the NPPFTP plugin cant connect any more :

It seems that NppFtp with LibSSH 0.6.5 is not compatible with the last openssh.

The text was updated successfully, but these errors were encountered:

What is the OpenSSH version and what is the environment it is using?

OpenSSH version :
SSH-2.0-OpenSSH_6.7 PKIX

Env :
Suse Linux Enterprise Server 11, level 2 3.0.101-0.7.23-xen #1 SMP Tue Aug 19 15:56:19 UTC 2014 (26d8f4e) x86_64 x86_64 x86_64 GNU/Linux

I got a similar complaint from a co-worker (so I don’t have the exact message, sorry), our SSH config follows recommendations from here.
We have OpenSSH 5.9, relevant piece of sshd config:

@jaymore, can you see something comparable in your /etc/ssh/sshd_config ?

It looks like diffie-hellman-group-exchange-sha256 is not supported even in the latest version of libssh (0.7.0), a patch was proposed in January but did not seem to have been merged yet as it is pending review. The only supported algorithms right now seem to be:

• diffie-hellman-group1-sha1
• diffie-hellman-group14-sha1
• ecdh-sha2-nistp256
• curve25519-sha256@libssh.org

@Mrten: looks like curve25519-sha256@libssh.org is the best choice as per the linked article and is supported, so that looks like your best bet.

Alas, OpenSSH 5.9 (from ubuntu precise) does not support that algorithm yet 🙂 I’ll add diffie-hellman-group14-sha1 for my coworker, thank you for the link to the libssh docs, but my comment was mainly meant to present an avenue to pursue.

@Mrten : sorry, i do not have read access to /etc/ssh/sshd_config on my server (I dont have a root access).

So I’m now sitting next to someone with NppFTP on a windows laptop, and after enabling diffie-hellman-group14-sha1 on the ssh server the exchange now fails on the same as above: [SFTP] Connection failed : kex error : no match for method mac algo client->server: server [hmac-sha2-512,hmac-sha2-256,hmac-ripemd160], client [hmac-sha1] .So I’ve enabled the mac and everything is peachy.

Have you got a timeframe for libssh 0.7.0? I understand sha256 is supported there.

@Mrten: I was unable to get it compiling, I use the same setup used for wkhtmltopdf for the dependent libs. Will have to try again as it looks like this issue will be solved by the upgrade.

Please let me know if it works for you with v0.26.4.

Remove the just-added hmac-sha1 from the config and it seems to continue working. Thanks!

As an issue for users of notepad++ that are trying to use ftp plugin to connect to the ssh or sftp from a recently updated debian server, just add «hmac-sha1» to the line of /etc/ssh/sshd_config . The issue here is that notepad’s++ ftp plugin uses hmac-sha1 to encode the ssh connection but latest ssh updates are working with hmac-sha2 only.

Line 89 of sshd_config (corrected):
MACs hmac-sha2-512,hmac-sha2-256,hmac-ripemd160,hmac-sha1

In my case the update worked perfectly.

I am having this issue can anyone help me.. Thanks !
kex error : no match for method mac algo client->server: server [hmac-md5,hmac-sha1-96,hmac-md5-96], client [hmac-sha1,hmac-sha2-256,hmac-sha2-512]

i updated Npp to 0.26.4

Looks like your server has not been updated as it uses too old and insecure algo support.

I understand it using hmac-md5-96 Is there a way to connect to that server/ i am not the admin to that server i just need to connect to that and work along, do we have older version of Npp that use same algorithms as server? Thanks for quick reply

I’m getting the below error while use the kex exchange in the SSH2.pm file.

20170706 15:26:01 Command «/apps/tfs/automation/tfs_exec.sh ./get_dli_tfs_files BMO» on host XXXXX failed execution by the Autosys ssh wrapper.
Return code from the command was 255.

msg: login to transfer server — ssh
msg: list files from remote server

2017-07-06 15:26:01 Could not get ls of /Out/bmo
Exit code=255
STDOUT=
STDERR=No kex algorithm at /usr/local/share/perl5/Net/SSH/Perl/SSH2.pm line 92

Below is the SSH2.pm files entry at 92 line.

my $kex = Net::SSH::Perl::Kex->new($ssh);
$kex->exchange;

can someone please help me with this error.

Источник

Debug SSH Connection issue in key exchange

Securing a server means hardening the SSH server settings, but doing so can also cause issues with ssh clients. Finding the cipher or algorithm causing a failled connection can be tricky. Depending on the client used, the error message might be very generic like “Failed to start SSH session”.

Using a openssh client will allow increasing the log level (-v) until the cause of the problem shows up in the output. Experience has shown that most issues are not related to openssh client configuration but closed source or third-party applications that provide less details via their user interface. In the case explained here it was an iPad/iPhone app, which had updated its ssh library. The app did not provide full details about the error as space is limited.

From the first error message “Failed to start SSH session: Unable to exchange encryption keys.” it was clear that there was a fundamental issue with the connection setup, but without any details from the client debugging had to be performed on the server side.

To debug the connection issue from the ssh daemon, the following log needs to be monitored on CentOS (other distributions might log to a different file).

In debian based distributions like Ubuntu, the log file for the ssh daemon is the following.

No matching MAC algorithem

The following line should be under the last lines of the log, indicating what the initial error message already suggested. Client and server could not setup a session as they could not agree on a MAC (message authentication code) algorithm.

But this error message already shows us more detail. It lists the client and server offered MACs. The client offered 6 MACs and the server offered 2, but no MAC is in both lists.

To continue debugging the connection issues the following MAC algorithm was enabled in the ssh daemon configuration, chosen at random from the client offered MAC algorithms. The resulting ssh daemon configuration after applying the settings from hardening the SSH server settings and with the added MAC algorithm looks like this.

After changing the configuration of the ssh daemon, sshd needs to be instructed to reload its configuration.

The next connection attempt shows the agreed MAC algorithm in “hmac-ripemd160” the log clearly.

No matching KEX algorithm

Even with the MAC algorithm agreed, the next problem might arise when the KEX (Key EXchange) algorithm can not be negotiated. The situation about the KEX negotiation is indicated very clearly.

Sadly this message does not provide any details about the proposed KEX algorithms from either side of the connection. To debug the connection on CentOS 6 running the OpenSSH 5.3 daemon, the debug level DEBUG2 is needed. To enable the logging on the ssh server, the following line of configuration has to be added to the /etc/ssh/sshd_config. It will not alter the behaviour of the ssh daemon itself, except to add additional logging to understand the decissions made during the connection setup. This configuration should be used with care on a busy ssh daemon as it increases the amount of logging significantly.

After changing the configuration of the ssh daemon, sshd needs to be instructed to reload its configuration again. The second command will open the log file to follow the login attempt.

With the increased log level, a connection attempt will look similar to this example (here I have removed the beginning of each line where there would normally be a timestamp and the host name).

There is no clear indication on the offered KEX algorithms in the log. To read this information out of the log, a deeper look into where the log lines come from is necessary. What’s interesting at this point are the log lines containing the “debug2: kex_parse_kexinit:”.

Digging into the logs

A quick peek into the function kex_buf2prop() of the file kex.c on branch V_5_3 of OpenSSH reads (shortened slightly) like this.

The function is called from kex_choose_conf() found in the same file. As the simplified example shows, this function is calling the above method twice.

Without digging deeper, the name of the parameters suggest, first the function is called with the locally configured algorithms and second with the offered algorithms from the remote. In this case, that would indicate that first the proposal from the ssh deamon is logged and the second block contains the proposal from the (remote) connecting client.

As such, the “kex_parse_kexinit” lines can be seperated into the following two blocks. The first one is the ssh daemon side.

• The 1st line appears to be the configured KEX algorithms (sshd_config option “KexAlgorithms”).
• The 2nd line appears to be the configured host key algorithms (sshd_config option “HostKeyAlgorithms”).
• The 3rd & 4th lines appear to be the configured ciphers (sshd_config option “Ciphers”).
• The 5th & 6th lines appear to be the configured MAC algorithms (sshd_config option “MACs”).

For some reason, which would probably require a deeper understanding of the source, the cipher and MAC list is shown twice. The block of “kex_parse_kexinit” lines ends with the line “kex_parse_kexinit: reserved 0”.

The second block is the proposals from the remote side, which is the ssh client trying to connect.

Knowing this, we can see that the KEX algorithms from the ssh daemon and the client’s proposed KEX algorithms do not have any algorithms in common, which causes the error message we saw earlier.

Of course, enabling one of the client’s proposed KEX algorithms would allow the client to login, but enabling one of these MAC or KEX algorithms needs to be handled with care. Many of the disabled ciphers and algorithms might be disabled for security reasons as described in Harden the SSH server settings.

As a proof, one of the client’s proposed KEX algorithms (I randomly chose “diffie-hellman-group-exchange-sha1”) can be enabled in the shh daemon. The configuration might look like this with the additional KEX algorithm.

After changing the configuration of the ssh daemon, sshd needs to be instructed to reload its configuration again.

The next login attempt from the client should succeed as the MAC and KEX algorithms the client proposes are enabled for the ssh daemon.

Modern distributions, different log

The above explanation about interpreting the log information to find the KEX that were offered applies to conservative distributions like CentOS 6 / RHEL 6 (Red Hat Enterprise Linux) and possibly Debian. But what about modern distributions? Modern distributions like Ubuntu and possibly more recent versions of CentOS and RHEL use a more up-to-date version of OpenSSH. At the time of writing Ubuntu uses OpenSSH 7.2 where the logging is more self explanatory.

The above example shows that instead of the “kex_parse_kexinit” log lines, the log identifies the offered algorithms. This makes it much easier to identify the MAC, KEX and ciphers offered from both sides. There is even a line between the blocks identifying the origin of the offer.

This way, guessing and digging in the source to understand the log is not needed any more. Sady not all distributions use the newer version of OpenSSH. With CentOS 6, OpenSSH 5.3 is still the latest, patched version available in the default repositories.

Источник

Pinkbyte, спасибо за отклик.

Удалось выяснить что sftp клиент пытается создать подключение посредством java

Caused by: com.maverick.ssh.SshException: Key exchange failed: Expected SSH_MSG_KEX_GEX_GROUP [id=3] [Unknown cause]
        at com.maverick.ssh.components.jce.DiffieHellmanGroupExchangeSha1.performClientExchange(Unknown Source)
        at com.maverick.ssh2.TransportProtocol.e(Unknown Source)
        at com.maverick.ssh2.TransportProtocol.processMessage(Unknown Source)
        at com.maverick.ssh2.TransportProtocol.startTransportProtocol(Unknown Source)
        at com.maverick.ssh2.Ssh2Client.connect(Unknown Source)
        at com.maverick.ssh.SshConnector.connect(Unknown Source)
        at com.maverick.ssh.SshConnector.connect(Unknown Source)

такую ошибку генерит класс DiffieHellmanGroupExchangeSha1.java из состава j2ssh-maverick:

final static int SSH_MSG_KEXDH_GEX_GROUP = 31;

byte[] tmp = transport.nextMessage();

			if (tmp[0] != SSH_MSG_KEXDH_GEX_GROUP) {
				transport.disconnect(TransportProtocol.KEY_EXCHANGE_FAILED,
						"Expected SSH_MSG_KEX_GEX_GROUP");
				throw new SshException(
						"Key exchange failed: Expected SSH_MSG_KEX_GEX_GROUP [id="
								+ tmp[0] + "]", SshException.INTERNAL_ERROR);

			}

Собственно из за этого кода и получается описание ошибки «Key exchange failed: Expected SSH_MSG_KEX_GEX_GROUP [id=3]»

Получается что при запросе SSH2_MSG_KEX_DH_GEX_REQUEST, ожидается получить код «31», чтобы подключение производилось далее по сценарию.

Если с клиента c OpenSSH_7.2p2 подключаться по «ssh -vvv» к удаленной станции с OpenSSH_5.3p1, то возвращается следующий стек:

debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(2048<3072<8192) sent
debug3: receive packet: type 31
debug1: got SSH2_MSG_KEX_DH_GEX_GROUP
debug2: bits set: 1511/3072
debug3: send packet: type 32
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug3: receive packet: type 33
debug1: got SSH2_MSG_KEX_DH_GEX_REPLY

а если же c клиента (с OpenSSH_5.3p1) к стации с (OpenSSH_5.3p1 или с OpenSSH_7.2p2), то будет будет получен стек такого плана:

debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<2048<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug3: Wrote 24 bytes for a total of 909
debug2: dh_gen_key: priv key bits set: 162/320
debug2: bits set: 1044/2048
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY

Как видно, в первом случае возвращается «type 31», а во втором — вообще не понятно откуда получается значение «3» ([id=3]).
Почему стек такой разный и как во втором случае увидеть откуда получается код «3»?
Быть может из за версии OpenSSH на клиенте изменяется стек?

damir77

(31.10.21 20:49:24 MSK)

Moderator: Project members

Aug  9 09:34:31 kelso sshd[805]: error: Hm, kex protocol error: type 30 seq 1 [preauth]
Aug  9 09:34:37 kelso sshd[805]: Connection reset by 123.123.123.123 [preauth]

debug2: kex_parse_kexinit: curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha