At 02:51 PM 12/5/2001 -0300, you wrote:

Who is you? me? I digress.

I presume you are referring to YOU when you say you (heh). YOU is SuSE's YaST Online Updater (Y O U) - but I presume "you" knew that and were teasing me.

Try enabling rsa logins, etc, etc in the config file. Just a wild and crazy idea.

You mean in /etc/ssh/sshd_config ? It already has: RSAAuthentication yes I tried un-commenting the following in /etc/ssh/ssh_config (they were commented out by default): Host * RSAAuthentication yes PasswordAuthentication yes IdentityFile ~/.ssh/identity IdentityFile ~/.ssh/id_dsa IdentityFile ~/.ssh/id_rsa I also changed Protocol 1,2 to Protocol 2,1 Because I don't want it defaulting to protocol 1. I've tried making new keys with rsa1, rsa, and dsa. None of them work. I'm not a pro at this. In each case I copied the contents of the .pub file to ~/.ssh/authorized_keys on the remote server - that's all I should really need to do, yes? In case it helps any, here's the output of ssh -v: jw@suse3:~ > ssh -v ccs008.claborn.net OpenSSH_2.9.9p2, SSH protocols 1.5/2.0, OpenSSL 0x0090601f debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Seeding random number generator debug1: Rhosts Authentication disabled, originating port will not be trusted. debug1: restore_uid debug1: ssh_connect: getuid 501 geteuid 501 anon 1 debug1: Connecting to ccs008.claborn.net [12.96.162.84] port 22. debug1: temporarily_use_uid: 501/100 (e=501) debug1: restore_uid debug1: temporarily_use_uid: 501/100 (e=501) debug1: restore_uid debug1: Connection established. debug1: identity file /home/jw/.ssh/identity type -1 debug1: identity file /home/jw/.ssh/id_dsa type 2 debug1: identity file /home/jw/.ssh/id_rsa type -1 debug1: Remote protocol version 1.99, remote software version OpenSSH_2.3.0p1 debug1: match: OpenSSH_2.3.0p1 pat ^OpenSSH_2\.3\.0 Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_2.9.9p2 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client 3des-cbc hmac-md5 none debug1: kex: client->server 3des-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST_OLD sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: dh_gen_key: priv key bits set: 201/384 debug1: bits set: 530/1024 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Host 'ccs008.claborn.net' is known and matches the DSA host key. debug1: Found key in /home/jw/.ssh/known_hosts:15 debug1: bits set: 488/1024 debug1: ssh_dss_verify: signature correct debug1: kex_derive_keys debug1: newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: waiting for SSH2_MSG_NEWKEYS debug1: newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: done: ssh_kex2. debug1: send SSH2_MSG_SERVICE_REQUEST debug1: service_accept: ssh-userauth debug1: got SSH2_MSG_SERVICE_ACCEPT debug1: authentications that can continue: publickey,password debug1: next auth method to try is publickey debug1: try privkey: /home/jw/.ssh/identity debug1: try pubkey: /home/jw/.ssh/id_dsa debug1: authentications that can continue: publickey,password debug1: try privkey: /home/jw/.ssh/id_rsa debug1: next auth method to try is password jw@ccs008.claborn.net's password: I just don't understand why it's failing.

-Kurt

----- Original Message ----- From: "JW" To: Sent: Thursday, December 06, 2001 2:31 PM Subject: [suse-security] Problems with OpenSSH after upgrading: private keys broken !

...

Hello,

Last night I installed the OpenSSH update from YOU, and this morning I found that all our public keys don't work anymore.

What's worse, generating new ones doesn't work either.

Several of our users have been using RSA keys for months now with no problem at all, we use them for backup jobs and other things where passwords would cause a problem.

We tried generating new RSA keys, that help . We also tried generating new DSA keys, that didn't help either.

Has anyone else had this problem?

Info for the box in question:

Linux fluorite 2.4.0-64GB-SMP #1 SMP Wed Jan 24 15:52:30 GMT 2001 i686 unknown SuSE Linux 7.1 (i386) VERSION = 7.1

Please note I did not download and update the box by hand, I used YOU.

If anyone could provide me with a work-around that doesn't require entering any sort of pass phrase (remember, programs that's can't type passwords need it, not humans) I'd really appreciate it.

Additionally, I'd like to know what caused the problem to begin with - I'm pretty surprised the upgrade broke they keys, I would think that would cause serious problems for a lot of people.

---------------------------------------------------- Jonathan Wilson System Administrator

Cedar Creek Software http://www.cedarcreeksoftware.com Central Texas IT http://www.centraltexasit.com

-- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com

---------------------------------------------------- Jonathan Wilson System Administrator Cedar Creek Software http://www.cedarcreeksoftware.com Central Texas IT http://www.centraltexasit.com

At 07:28 PM 12/6/2001 +0100, you wrote:

JW wrote:

...

I'm not a pro at this. In each case I copied the contents of the .pub file to ~/.ssh/authorized_keys on the remote server - that's all I should really need to do, yes?

I just don't understand why it's failing.

you need to copy the new DSA Key to authorized_keys2, notice the 2.

Thanks, I tried that, that also does not work on the new servers but curiously it fixes the problem with the remote servers that havn't been updated yet. According to the man page you don't have to use "2": jw@fluorite:~/.ssh > man ssh-keygen $HOME/.ssh/id_rsa.pub Contains the protocol version 2 RSA public key for authentica­ tion. The contents of this file should be added to $HOME/.ssh/authorized_keys on all machines where the user wishes to log in using public key authentication. There is no need to keep the contents of this file secret. (same for dsa) But on the old version man page it _does_ say you have to use authorized_keys2 for dsa specifically.

After all, a look into the logfile of the Server you're connecting to would help. Maybe a permissions problem.

Ah!, now this is curious(why didn't I think of that...): Dec 6 12:41:31 fluorite sshd[32564]: Authentication refused: bad ownership or modes for file /home/jw/.ssh/authorized_keys Dec 6 12:41:31 fluorite sshd[32564]: Authentication refused: bad ownership or modes for file /home/jw/.ssh/authorized_keys2 -rw-rw-r-- 1 jw users 218 Dec 6 12:35 authorized_keys -rw-rw-r-- 1 jw users 218 Dec 6 12:35 authorized_keys2 I also tried removing the group w bit, then the user w bit - which caused the error to change to: Dec 6 12:47:03 fluorite sshd[32712]: Authentication refused: bad ownership or modes for directory /home/jw I have my home group writable, we all do for certain reasons. I removed the g+w bit and they key worked - I wasn't asked for a password. This is a SERIOUS problem - on our remote servers we have a certain use we all use at times that _has_ to have g+w. Is there a way to tell sshd to ignore the fact that ~ has the g+w bit?

-- intraDAT AG http://www.intradat.com Wilhelm-Leuschner-Strasse 7 Tel: +49 69-25629-0 D - 60329 Frankfurt am Main Fax: +49 69-25629-256 Junk mail is war. RFCs do not apply.

---------------------------------------------------- Jonathan Wilson System Administrator Cedar Creek Software http://www.cedarcreeksoftware.com Central Texas IT http://www.centraltexasit.com