ssh.Dial return error: ssh: no common algorithms

[Hill]

Hi,
"code.google.com/p/go.crypto/ssh", I have a little program which using
this package to connect
a ssh server, the code is almost same from the document from the
package:

func SshConnect(host string, user string, passwd string)(*SshConn,
error){
config := &ssh.ClientConfig {
User: user,
Auth: []ssh.ClientAuth
{ssh.ClientAuthPassword(password(passwd)),},
}

clientConn, err := ssh.Dial("tcp", fmt.Sprintf("%s:22", host),
config)
if err != nil{
return nil, err
}
this := &SshConn{host, clientConn}
return this, nil
}

When I use this code to connect a cygwin ssh server, which is
installed on my localhost, all is right.
But when I using it connect to another ssh server, which I know is a
customized linux, ssh.Dial
always return error: "ssh: no common algorithms"
I doesn't know exactly what difference between the two ssh servers,
But How to fix this?

I am using gowin386_weekly.2012-02-14.

Thanks!

[Dave Cheney]

Hello,

It may not be fixable directly by you. If you look in

http://code.google.com/p/go/source/browse/ssh/cipher.go?repo=crypto#69

these are the ciphers currently supported. If you use ssh -vv against
your local server, then your customized server, you may be able to
determine which ciphers are not available on your customised servers.

Depending if there is a crypto library for the missing cipher, it may
be either simple, or difficult to add support to the ssh package.

Cheers

Dave

[Hill]

I think the ssh server is not using special cipher or something, It
can also
be connected normally by SSH client tools like PUTTY or linux ssh
command.
from the doc of the code, It seems not all of the cipher algorithms is
supported.

// Specifies a default set of ciphers and a preference order. This is
based on
// OpenSSH's default client preference order, minus algorithms that
are not
// implemented.

[John Beisley]

The error message looks to be from http://code.google.com/p/go/source/browse/ssh/client.go?repo=crypto#90 - which is unfortunately not specific as to which type of algorithm (cipher/kex/host key/mac) agreement could not be found on - so it might not necessarily be the cipher.

http://code.google.com/p/go/source/browse/ssh/common.go?repo=crypto#17 shows the algorithms available for key exchange (kex), host key, and MAC - for each of which there is only one supported algorithm. I would like to see portions of `ssh -vv $serverhost true 2>&1 | grep kex_parse_kexinit` to find which algorithms are available.

- John

[Zhu Bicen]

>I would like to see portions of `ssh -vv $serverhost true 2>&1 | grep kex_parse_kexinit` to find which algorithms are available.

The server is not accessible during weekend. I'll run the command and show you the result next Monday. 

Thanks for your help.

Best Regards
Hill

[Hill]

Hi,
The result is as below, Could you please help me check it?
Thanks in advance.

$ ssh -vv 192.168.255.1 true 2>&1 | grep kex_parse_kexinit
debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-
sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-
group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-
sha1
debug2: kex_parse_kexinit: ecdsa-sha2-nistp256-cert-
v...@openssh.com,ecdsa-sha2-nis...@openssh.com,ecdsa-sha2-
nistp521...@openssh.com,ssh-rsa-...@openssh.com,ssh-dss-
cert...@openssh.com,ssh-rsa-...@openssh.com,ssh-dss-cert-
v...@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-
nistp521,ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-
ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-
cbc,aes192-cbc,aes256-cbc,arcfour,rijnda...@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-
ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-
cbc,aes192-cbc,aes256-cbc,arcfour,rijnda...@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,uma...@openssh.com,hmac-
sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-
ripemd160,hmac-ri...@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,uma...@openssh.com,hmac-
sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-
ripemd160,hmac-ri...@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zl...@openssh.com,zlib
debug2: kex_parse_kexinit: none,zl...@openssh.com,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-
sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-
group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-
sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256
debug2: kex_parse_kexinit: aes192-cbc,aes192-ctr,aes128-cbc,aes128-
cbc,aes256-cbc,aes256-ctr
debug2: kex_parse_kexinit: aes192-cbc,aes192-ctr,aes128-cbc,aes128-
cbc,aes256-cbc,aes256-ctr
debug2: kex_parse_kexinit: hmac-sha1,hmac-ripemd160
debug2: kex_parse_kexinit: hmac-sha1,hmac-ripemd160
debug2: kex_parse_kexinit: none,zl...@openssh.com
debug2: kex_parse_kexinit: none,zl...@openssh.com
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0

[John Beisley]

Ah, I believe I see the trouble. In your ssh -vv output it shows that one side only supports "hmac-sha1,hmac-ripemd160" for the MAC algorithm (I'm thinking that this is the server's responding kexinit message). However, the SSH package only supports "hmac-sha1-96" - so they cannot agree on a MAC algorithm. It looks okay from the KEX and host-key algorithms point of view.

So the possible solutions that I see are:

1. enable the hmac-sha1-96 algorithm on the server,

2. hack/patch the SSH library to change its MAC algorithm to one of the server's algorithms,

3. extend the SSH library to support multiple algorithms, including at least one of the server's algorithms.

Option 1 or 2 are potentially the quickest solutions.

Option 2 looks like this to support hmac-sha1 (I'm pretty sure, at least :)

* Change a line in transport.go:

from: c.mac = truncatingMAC{12, hmac.New(sha1.New, macKey)}

to: c.mac = hmac.New(sha1.New, macKey)

* And a couple of lines in common.go:

from: macSHA196       = "hmac-sha1-96"

to: macSHA1       = "hmac-sha1"

and:

from: var supportedMACs = []string{macSHA196}

to: var supportedMACs = []string{macSHA1}

Option 3 is ultimately the better solution, but I can't commit to finding time to get such a change in in the near future.

[Hill]

Hi John, Thank you for your big help! I have hacked the code as your
advice,
And It has passed the compilation. I'll try to test it tomorrow
morning. :D

[Hill]

I select the option2, and It work. :D
Should I or someone report a bug to the go.crypto/ssh library?

On 2月20日, 下午6时20分, John Beisley <h...@google.com> wrote:

[John Beisley]

Excellent! A bug/feature request would be good to track this as you suggest.

[Dave Cheney]

I've been having a think about this, as you say it's larger than a
small job, so an issue would be welcome.

Cheers

Dave

[Hill]

YES. I have reported one,  http://code.google.com/p/go/issues/detail?
id=3095
:D

[Dave Rose]

I see the patch in the code review... but it seems that the issue is still not supported? does that mean that support for SHA1 3DES CBC won't be supported in the general ssh packge?

[Dave Cheney]

I don't think this issue is related to CBC mode cyphers being supported or not. Could you please open a fresh issue or a new thread of discussion. 

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.