We recently install a Suse Linux Server version 8 however we are experiencing technical issues with the public keys which reside on a AIX 4.3.3 running F- Secure Server. We regenerated the keys a multiple time but the problem is always there. To generate the keys we use the following command(usr/bin/ssh- keygen -b 1024 -t dsa) and then we convert the pub file so the F-Secure can read it(ssh-keygen -e -f KEY_OPENSSH.pub > KEY_FSECURE.pub). We aren't able to connect with the public keys however we can connect with a password directly to the F-Secure Server. PLEASE HELP! Debug Mode ========================================================== OpenSSH_3.4p1, SSH protocols 1.5/2.0, OpenSSL 0x0090607f 32459: debug1: Reading configuration data /etc/ssh/ssh_config 32459: debug1: Applying options for * 32459: debug1: Rhosts Authentication disabled, originating port will not be trusted. 32459: debug1: ssh_connect: needpriv 0 32459: debug1: Connecting to 172.21.43.135 [172.21.43.135] port 10022. 32459: debug1: Connection established. 32459: debug1: identity file /root/.ssh/id_dsa type -1 32459: debug1: Remote protocol version 2.0, remote software version 2.3.1 F- SECURE SSH 32459: debug1: match: 2.3.1 F-SECURE SSH pat 2.3.* 32459: Enabling compatibility mode for protocol 2.0 32459: debug1: Local version string SSH-2.0-OpenSSH_3.4p1 32459: debug1: SSH2_MSG_KEXINIT sent 32459: debug1: SSH2_MSG_KEXINIT received 32459: debug1: kex: server->client 3des-cbc hmac-md5 none 32459: debug1: kex: client->server 3des-cbc hmac-md5 none 32459: debug1: dh_gen_key: priv key bits set: 184/384 32459: debug1: bits set: 489/1024 32459: debug1: sending SSH2_MSG_KEXDH_INIT 32459: debug1: expecting SSH2_MSG_KEXDH_REPLY 32459: debug1: Host '172.21.43.135' is known and matches the DSA host key. 32459: debug1: Found key in /root/.ssh/known_hosts:1 32459: debug1: bits set: 544/1024 32459: debug1: ssh_dss_verify: signature correct 32459: debug1: kex_derive_keys 32459: debug1: newkeys: mode 1 32459: debug1: SSH2_MSG_NEWKEYS sent 32459: debug1: waiting for SSH2_MSG_NEWKEYS 32459: debug1: newkeys: mode 0 32459: debug1: SSH2_MSG_NEWKEYS received 32459: debug1: done: ssh_kex2. 32459: debug1: send SSH2_MSG_SERVICE_REQUEST 32459: debug1: service_accept: ssh-userauth 32459: debug1: got SSH2_MSG_SERVICE_ACCEPT 32459: debug1: authentications that can continue: publickey 32459: debug1: next auth method to try is publickey 32459: debug1: try privkey: /root/.ssh/id_dsa 32459: debug1: PEM_read_PrivateKey failed 32459: debug1: read PEM private key done: type <unknown> 32459: debug1: no more auth methods to try 32459: Permission denied (publickey). 32459: debug1: Calling cleanup 0x8068090(0x0) 32458: Couldn't read packet: Connection reset by peer ======================================================== ssh_config file Host * BatchMode yes StrictHostKeyChecking ask IdentityFile ~/.ssh/id_dsa Port 9022 HELP!
Please do *not* paste debug logs in the text fields. It makes bugs difficult read. Use "Create Attachment" instead. This bit from the log: 32459: debug1: try privkey: /root/.ssh/id_dsa 32459: debug1: PEM_read_PrivateKey failed 32459: debug1: read PEM private key done: type <unknown> makes it look like either the key is corrupt or ssh can't read it. Can openssl read the key? Try "openssl dsa -in /path/to/id_dsa -noout". Can you reproduce this problem with the current version of OpenSSH, compiled from source?
Thanks for the reply, The file is not corrupt due to multiple times we regenerate new keys however it makes me believe that OpenSSH maybe is unable to read it like you mentionned. Unfortunetaly we have an older version of OpenSSH_3.4p1 which we can not upgrade due to productivity issues and reasons from ours customers. I don't seems do understand your comment about openssl? Can openssl read the key? Try "openssl dsa -in /path/to/id_dsa -noout".
Here are the results of the openssl command : read DSA key unable to load Key 19040:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:663:Expecting: ANY PRIVATE KEY
It looks like your key is corrupt or in the wrong format. OpenSSH DSA private keys look like this: -----BEGIN DSA PRIVATE KEY----- MIIBuwIBAAKBgQCtCj2pc4Jh6uJGpJTx6AjS2LHdl0O/Addq2rzi7Fl8+om2yL1W Ks/nxVLGeQxuNKiXltP44ydA0X3ZV0oL36/AFR2EBp+2kvXgidEaPeCdADxHERmA IzXt6bg8E6SCOUDDmry7cksggeCh1FYHdImE3eS79b7XP8FOSKaWoHlsEwIVANyh eqPATKbvznXOS0w3RtC7sTQLAoGAJlcK7VS7K4KkGyGw+5na8ygR8R8hP+xpyp/J J0QZw0FFj5hGOSn5eFmSDoPCHFp0huydEeLutqgbxxmUQon/XJN0JxlijAm/HCx4 fWnzBRKKtEPvoK75B2+i8/EJvEOzA9PZ7wetExKRQdYOy3SuCupMJQrLsfe0R33O Sw/sRuYCgYAgW9bjuZbyXTDCkej3mWSuiiiGRppgSLjF7hwCuFHjXMKK77oVr5AZ 8eBbzYzMkeEVtyWsIElScNRoUMLN3gOF/eQvweyWm5JhEJC3nOpBk9fim+j9vr5m gIkosMXyZYeynnT/bqjb4QJXZnqO4mqMDEHl/1siIPBagfO9/BgC2QIVAJ3xoe2o rXABTs/bnP+1EjdEvsm5 -----END DSA PRIVATE KEY----- Does your key look anything like that?
OpenSSH private keys are PEM-format which the "openssl" command understands. OpenSSH just uses OpenSSL's functions to read and write them, so if the openssl command can't read the key either then your problem lies with OpenSSL not OpenSSH. Either way, if your vendor-supplied OpenSSH packages don't work and you're unwilling or unable to change them then there's nothing we can do to help you, you need to report the problem to your vendor.
My Private Keys look like this: -----BEGIN DSA PRIVATE KEY----- Proc-Type: 4,ENCRYPTED DEK-Info: DES-EDE3-CBC,412062178CB9200B BJUpGFHniNZu/CE846YGKRmNRY8xMz23gEY9ZV6bFcmpFJ2NMCkbu6ICezkYWjxv 2Jh3Xw3YkHltChMzmqjExlCLqgV0iYPnzALN54uUeX3/bNmkiHj7h5aJAmnc51n4 4/oDR/F9yXLxkNBPc12gp67MODLqI3SLsEUKEpEipZFM+RLiHVZkfCKSUdVBWAVl nq4AalY5Gm7Z91HQ/dK8/PB1jcVwYDXFHChFi+oiSySrhfUjQk2aBSqeJY7/iSq7 aR1qke86Ugb+8K+edUVeKXyeM79nbnj1XbJwwdgX1TyG6v4Wo+d/6SknCMdLDjro sHo34ygn0D/Yo1Tez2JGk7bb5Cov9vKc0WyLjQshb40Fh3pfW1z8VxEwz3c0yKnf RS9gc1V5xwZXjnh/lQ0OXejfPBJexWmQhDwikDGUKyTgaO8QJX8TDUXIAm2ZXST7 g+x1OU4NTUxAUDJYw5G0SD8V0iSlP8qd+wqVkwSYO2TFmlqifUKdAdbVJG17F4Z2 COf5wIk48+VTNpbwA13d/8i0HOXBRI6Q1SwnBOuLWF+J0FprGh3UrPz5n9C3v1IY xURH3KgH7x4GnYwW6BxdsA== -----END DSA PRIVATE KEY-----
Like in my previous note I generate the key with the following comand: /usr/bin/ssh-keygen -b 1024 -t dsa
yume:~ mouring$ ssh-keygen -b 1024 -t dsa Generating public/private dsa key pair. Enter file in which to save the key (/Users/mouring/.ssh/id_dsa): xxx Enter passphrase (empty for no passphrase): testme Enter same passphrase again: testme Your identification has been saved in xxx. Your public key has been saved in xxx.pub. The key fingerprint is: b6:5a:2c:24:2d:32:4a:40:c9:b4:13:0e:12:65:d9:ce mouring@yume.local yume:~ mouring$ cat xxx -----BEGIN DSA PRIVATE KEY----- Proc-Type: 4,ENCRYPTED DEK-Info: DES-EDE3-CBC,5D45E766C929404A OUKT6wiDFO9HNVPis7IEoQtBGCeiHHAm8j0PyqcVCDCwpRnGSYEIrY2avkth/ohd MPeW+aL08uB3b0c+67gF35ucJOGNVyzXue6izojJKB/ZoPCfdUpQGnnkNF/MsUok ymEhzvg0ZF29qilaQeVbSE7MJnQupAiU5pa0TzeoUvlBtlxTVPlenaNt3CPj8KIU QPKMNsHFWuyMHKk9MKc7uDWCJB4VtZbfrnrafUig+gisncpyhTQsU7fwzRTkUUI9 NNKFTx9jWXLN6CJGSw3Ju58J0CmbmH0dyGUfzRCvLoWKltu8sI/wk/tGE646BooM WltvqcY7SGjl0Md7HYAZf0tPGgyW+7TyAczJwuGqMmuDW5rqeQ/SOXoxkM76y1iM jqzZhGoZ4WGFxbYgiVn8b1x1SCeKLp/digsidThXsab65z0VrTaB3kl6FhEFWJo8 AwSn6NNrgOMViYVZWKsTPtFPfIJy3E9LieC0Qo0vJBca3HSTqMGWOEzSQWprQPyc VCYWtXW7Sh1j7fVqdN8G/E5nV3CpVuLjxZgvOuDqrFyf+OWsjReAruAYgsmCwQsu c7qNaH3CNkUgfJvk7Joj4w== -----END DSA PRIVATE KEY----- yume:~ mouring$ openssl dsa -in xxx -noout read DSA key Enter PEM pass phrase: testme yume:~ mouring$ That is what you should see. By the fact that "openssl" is not accepting the dsa key means something went wrong while generating it. 3.4p1 is pretty old and unless patched has at least one security issue assocated with it. I'm remarking this as a ssh-keygen issue and marking it down to "normal" unless you can prove the current release shows the same issue.
Thanks guys for the information, we found the problem! We regenerate the key the following command : ssh-keygen -t dsa instead of the previous command! It works!
I copied the key locally and openssl gets as far as asking for a password, so it looks OK. I suspect the problem is in the DSA key read routines in OpenSSL. A bit of googling turned up this similar problem: http://www.mail-archive.com/openssl-dev@openssl.org/msg09884.html which was tracked to a compiler bug in gcc-3.0 causing a miscompile of OpenSSL.