LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Networking (https://www.linuxquestions.org/questions/linux-networking-3/)
-   -   Why does my public key authentication not work with all machines? (https://www.linuxquestions.org/questions/linux-networking-3/why-does-my-public-key-authentication-not-work-with-all-machines-192079/)

BrianK 06-10-2004 05:40 PM

Why does my public key authentication not work with all machines?
 
I've got 15 machines in my office. I just generated my id_dsa.pub & copied it to the ~/.ssh/authorized_keys2 on all the machines, but it only seems to work properly on about half of them. What could be going wrong?

if I ssh -vv to a working and non working host, I get the following differences:

working:

debug2: we sent a publickey packet, wait for reply
debug1: input_userauth_pk_ok: pkalg ssh-dss blen 433 lastkey 0x8086e20 hint 2
debug2: input_userauth_pk_ok: fp a3:3e:bc:f8:52:2e:ec:9d:15:03:43:f4:0f:25:d7:51
debug1: read PEM private key done: type DSA
debug1: ssh-userauth2 successful: method publickey


not working:

debug2: we sent a publickey packet, wait for reply
debug1: authentications that can continue: publickey,password,keyboard-interactive
debug2: we did not send a packet, disable method
debug1: next auth method to try is keyboard-interactive
debug2: userauth_kbdint
debug2: we sent a keyboard-interactive packet, wait for reply
debug1: authentications that can continue: publickey,password,keyboard-interactive
debug2: we did not send a packet, disable method
debug1: next auth method to try is password
debug1: packet_send2: adding 48 (len 61 padlen 19 extra_pad 64)
debug2: we sent a password packet, wait for reply
debug1: ssh-userauth2 successful: method password


why is it doing that? Is it because they are all not running the same version of openssh? Do I have to tell the host to allow public key explicitly?

mritch 06-10-2004 06:43 PM

looks like your sshd is not configured right (see sshd.conf) on the failing machines. it seems that it can't get the key from your host - more information is necesssary here. network-topologie, config's,..
an other possibility is the "authorized_key2" - try to change back to just call it "authorized_key" on those machines. are they all the same os (and ssh2 only)?

sl mritch.

BrianK 06-14-2004 06:02 PM

Quote:

Originally posted by mritch
looks like your sshd is not configured right (see sshd.conf) on the failing machines. it seems that it can't get the key from your host - more information is necesssary here. network-topologie, config's,..
an other possibility is the "authorized_key2" - try to change back to just call it "authorized_key" on those machines. are they all the same os (and ssh2 only)?

sl mritch.

Hello and thanks for the help...

the sshd.conf on a good machine vs bad machine is almost identical & both are pretty vanilla - just the way they came out of the box.

Code:

Title = "SSHD"

LogFile = secure
LogFile = messages

*OnlyService = sshd
*RemoveHeaders

(that's from a non working box - one of the working boxes doesn't have "title" or "LogFile = messages", but is otherwise the same).

I've tried using both authorzied_keys and authorized_keys2.

All machines are running linux, some are running RH7.3, some are running RH9.x - whether they work or not does not seem to depend on their version (i.e. some 7.3 boxes work, some 9.x boxes work).

network topology: pretty simple, really, my machine and all the machines I'm trying to connect too are all patched into one 24 port unmanaged switch. There are two other switches attached to that switch, but I'm not working with those machines yet.

any other ideas? Do you need any more specific info?

Thanks again

linuxxed 06-14-2004 06:46 PM

have you done a "diff" of /etc/ssh/sshd_config on the good vs bad machines?

Check permissions and ownership of authorized_keys2 file. If you have copy and pasted it then it might not work.

BrianK 06-14-2004 07:12 PM

Quote:

Originally posted by linuxxed
have you done a "diff" of /etc/ssh/sshd_config on the good vs bad machines?

% diff sshdwork sshdbroke
1c1
< # $OpenBSD: sshd_config,v 1.48 2002/02/19 02:50:59 deraadt Exp $
---
> # $OpenBSD: sshd_config,v 1.59 2002/09/25 11:17:16 markus Exp $
3,4c3,4
< # This is the sshd server system-wide configuration file. See sshd(8)
< # for more information.
---
> # This is the sshd server system-wide configuration file. See
> # sshd_config(5) for more information.
6c6
< # This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin
---
> # This sshd was compiled with PATH=/usr/local/bin:/bin:/usr/bin
36c36
< #LoginGraceTime 600
---
> #LoginGraceTime 120
40,42c40,42
< #RSAAuthentication yes
< #PubkeyAuthentication yes
< #AuthorizedKeysFile .ssh/authorized_keys
---
> RSAAuthentication yes
> PubkeyAuthentication yes
> AuthorizedKeysFile .ssh/authorized_keys
64,65c64
< # KerberosAuthentication automatically enabled if keyfile exists
< #KerberosAuthentication yes
---
> #KerberosAuthentication no
69,70c68
< # AFSTokenPassing automatically enabled if k_hasafs() is true
< #AFSTokenPassing yes
---
> #AFSTokenPassing no
77c75
< #PAMAuthenticationViaKbdInt yes
---
> #PAMAuthenticationViaKbdInt no
86a85,87
> #UsePrivilegeSeparation yes
> #PermitUserEnvironment no
> #Compression yes



edit: just for grins, I copied the sshd_config file over from a working machine to a non-working machine & restarted sshd. still no good. :confused:

Quote:


Check permissions and ownership of authorized_keys2 file. If you have copy and pasted it then it might not work.

permissions on both auth_keys and auth_keys2 == 600 (o+rw)

chort 06-15-2004 01:27 AM

If your network is very congested and the login takes a while, you may be exceeding the grace time (although that's highly unlikely). Another thing may be that the format of the authorized_keys file is wrong on some of the boxes. It's important that you transfer the file as text rather than binary data, and it's also important that there are no line breaks inserted. Trying diff'ing the actual authorized_keys file on a working and non-working box.

BrianK 06-15-2004 01:59 AM

Quote:

Originally posted by chort
If your network is very congested and the login takes a while, you may be exceeding the grace time (although that's highly unlikely). Another thing may be that the format of the authorized_keys file is wrong on some of the boxes. It's important that you transfer the file as text rather than binary data, and it's also important that there are no line breaks inserted. Trying diff'ing the actual authorized_keys file on a working and non-working box.
hmm... I'm 99.9% sure that network traffic has nothing to do with it being that all machines are on the same network and the machines that don't work are very consistant in their not working.

diffing the auth_keys shows no difference.

Glad to see that everyone else is as stumped as me. ;)

Any other suggestiong?

BrianK 06-18-2004 07:10 PM

Got it working. It was a permissions issue for the .ssh directory itself. It had to much permission, so it wouldn't work (weird).

I chmoded it to 700 (from 755), and everything works.

chort 06-18-2004 08:30 PM

That's correct, no one should be allowed to see your keys, or especially your trusted host list.


All times are GMT -5. The time now is 01:37 AM.