Why does my public key authentication not work with all machines?
Linux - NetworkingThis forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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?
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)?
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.
(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?
Distribution: OpenBSD 4.6, OS X 10.6.2, CentOS 4 & 5
Posts: 3,660
Rep:
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.
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.