Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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.

share|improve this question

migrated from stackoverflow.com May 1 '12 at 9:13

This question came from our site for professional and enthusiast programmers.

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

3 Answers 3

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.

share|improve this answer

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.

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

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

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.