0

The authorized keys files on both machines are the same. So, I am unaware of any other thing to check ..

On the one that works (host A->B) I get ..

debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering DSA public key: foo.macbook.air
debug1: Server accepts key: pkalg ssh-dss blen 433
debug1: Authentication succeeded (publickey).

On the one that doesn't work (host B->A) I get :

debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/foo/.ssh/id_rsa
debug1: Trying private key: /home/foo/.ssh/id_dsa

The /etc/ssh/ssh_config files are the same on both hosts. and my ~/.ssh/authorized_keys is identical on both hosts, with permissions 600. ~/.ssh also has permissions 600.

Is the problem potentially that public key is not being 'Offered' by host B for some reason? I am at a loss as everything works one way, but not the other, and I can't see any obvious differences between the two servers.

dave4420
  • 833
  • 5
  • 5
Don Wool
  • 111
  • 3
  • 1
    Should be on Server Fault? – Eugene S May 01 '12 at 06:37
  • Or on SuperUser –  May 01 '12 at 08:17
  • Are your private keys stored on both A and B? Or on a third host from which you ssh in in the first place, with the key agent being forwarded? – dave4420 May 01 '12 at 08:55
  • 1
    You gave us the permissions on `~/.ssh/authorized_keys`, but not on `~/.ssh` itself, and they're also important. Could you update? – MadHatter May 01 '12 at 09:18
  • 1
    @dave yeah I have SecureCRT with port-forwarding to both hosts. So as I understand it, no private keys are on either Host. I currently, when I try ssh or scp, have a SecureCRT session up and active to both hosts. – Don Wool May 01 '12 at 15:05
  • Hi the permissions on .ssh directory are drwx------. Thx for the help guys. much appreciated. let me know if there is any other info I can include. – Don Wool May 01 '12 at 15:09
  • Check the security logs on either server right after the failed attempt and see if they shed any light. – Safado May 01 '12 at 20:11

3 Answers3

1

The problem had to do with SecureCRT. I deleted the hostsmap.txt file.

C:\Documents and Settings\%user%\Application Data\VanDyke\Known Hosts\hostsmap.txt

Somehow the problem boiled down to a host key issue.

Bart De Vos
  • 17,911
  • 6
  • 63
  • 82
Don Wool
  • 111
  • 3
0

Having an identical authorized_keys on both hosts will not work. Host A needs the public key from B in it's authorized_keys, while Host B needs A's public key.

ott--
  • 1,091
  • 1
  • 11
  • 13
  • The keys are not specific to a host; if both users on each box use the same key pair, it most certainly will work. – adaptr May 01 '12 at 09:29
  • I assumed he used ssh-keygen twice, one time on A the the other one on B. – ott-- May 01 '12 at 09:47
  • Since he never states anything of the sort, I didn't assume it ;) – adaptr May 01 '12 at 10:03
  • Well, normally we would assume that he did the logical thing. I, like ott, assumed that each server had it's own unique key pair. If each server is using the same key pair, that means they're sharing an identity, which is stupid. Maybe in his case they're break boxes or boxes that simply don't matter.. but still... – Safado May 01 '12 at 20:09
  • Hi, trying to explain this better. first, both servers matter! second, I just have one authorized key (which is the same) on both servers. This is the public key. second, I connect through CRT, so the private key is on a PC (or on a MAC via iTerm). if I set up CRT to do port forwarding, shouldn't I be able to not have to have a private key on either server? – Don Wool May 01 '12 at 21:30
0

There should be a private key on B whose public counterpart would be an entry in authorized_keys on A; and vice versa.

yrk
  • 2,487
  • 17
  • 22