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.

7
  • 1
    Should be on Server Fault?
    – Eugene S
    May 1, 2012 at 6:37
  • Or on SuperUser
    – user80295
    May 1, 2012 at 8: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 1, 2012 at 8: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 1, 2012 at 9: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 1, 2012 at 15:05

3 Answers 3

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.

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.

5
  • 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 1, 2012 at 9:29
  • I assumed he used ssh-keygen twice, one time on A the the other one on B.
    – ott--
    May 1, 2012 at 9:47
  • Since he never states anything of the sort, I didn't assume it ;)
    – adaptr
    May 1, 2012 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 1, 2012 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 1, 2012 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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .