Well, something is certainly accepting the pubkey so it could be AgentForwarding. if you echo $SSH_AUTH_SOCK is the variable defined? and does a process list show ssh-agent running? Also, check /etc/ssh to see if there's a authorized keys file there. Cheers, Harry On 05/14/2013 03:12 PM, Lucas, Brandon wrote: > I also wouldn't expect SSH to work that way but that is indeed the behavior as I have described. The three "bear" accounts all have the exact same id_rsa.pub file and authorized_keys entries, which list the "teddy" account on the fourth server. This relationship was set up so that I could push continuous code builds from the "teddy" server to any 3 of the "bear" servers. > > The secure log on a server I am connecting to, is showing on successful connection as if there was a key pair set up for the "bear" user between the servers: > > May 14 14:06:18 bearServer sshd[4199]: Accepted publickey for bear from xx.xx.xx.xx port 54305 ssh2 > May 14 14:06:18 bearServer sshd[4199]: pam_unix(sshd:session): session opened for user bear by (uid=0) > > .. but this key pair does not exist. If I were to look at authorized keys on the server I connected to I see: > > ssh-rsa HASH== teddy@xxxxxxxxxxxxxxxxxxxxxx > > ...with the id_rsa.pub saying the same thing. > > > The home directory is not NFS mounted, nor did we do an ssh-add. When connecting I am simply using "ssh bearServer.domain.com" when logged in as the "bear" user on one of the 3 servers, and I get right in. > > I found a forum posting where someone online was seeing the exact same behavior but for the life of me I cannot find the forum posting now. In their case they suggested that AgentForwarding was the cause. > > > -----Original Message----- > From: redhat-list-bounces@xxxxxxxxxx [mailto:redhat-list-bounces@xxxxxxxxxx] On Behalf Of m.roth@xxxxxxxxx > Sent: Tuesday, May 14, 2013 12:36 PM > To: General Red Hat Linux discussion list > Subject: Re: SSH Unexpectedly Not Prompting for Password > > Lucas, Brandon wrote: >> >> I have a question about SSH that I can't seem to figure out. Here is the >> situation: >> >> 4 servers on RHEL 6.3 > > You really should update to 6.4, for security reasons if nothing else. >> >> One server has a local account ("teddy"). SSH key pairs have been set up >> between this "teddy" account and the other 3 servers on a different local >> account common to the other 3 servers ("bear"), but not present on the >> "teddy" server. These 3 servers do not have a "teddy" account. >> >> Now, I am able to ssh without password between the 3 "bear" servers using >> the "bear" account without a password. This behavior is undesired as it >> bypasses some key controls. >> >> I figure what must be happening here is that since the 3 "bear" servers >> have the same public key that points to the "teddy" server, they must be >> using that fourth server as some type of "witness" to verify the identity >> of the user making the ssh connection, bypassing the password for the >> "bear" account. I have disabled AgentForwarding on all 4 servers in >> question, as well as X11Forwarding. This has not helped. >> >> What is going on here and how do I avoid it? > > As someone else said, ssh doesn't work that way. Question 1: where's your > home directory - it's not NFS mounted, is it? Second, did you do an > ssh-add on teddy, first? Third, are you doing ssh -A? > > mark > -- redhat-list mailing list unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe https://www.redhat.com/mailman/listinfo/redhat-list