ssh connection fails

Question

Level 1

0 points

ssh connection fails

I used to have this running but now it won't work. Starting afresh, I deleted the various keys under .ssh folder on REMOTE and generated public/private keys for both RSA and DSA using ssh-keyge. I then copied the public rsa key to authorized_keys on the other LOCAL computer, and the public dsa key to authorized_keys2 on the LOCAL computer. Then from that computer, I try to log back onto REMOTE. I've triple-checked the password, and it fails. Even the user password fails (a final option given). Does anyone know why? I'd really appreciate the help as I need this for remote debugging. Thanks.

Running in verbose, I get these messages:

OpenSSH_5.1p1, OpenSSL 0.9.7l 28 Sep 2006
debug1: Reading configuration data /etc/ssh_config
debug1: Connecting to <LOCAL COMPUTER>.local [SOME KEY] port 22.
debug1: Connection established.
debug1: identity file /Users/<myname>/.ssh/identity type -1
debug1: identity file /Users/<myname>/.ssh/id_rsa type 1
debug1: identity file /Users/<myname>/.ssh/id_dsa type 2
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1
debug1: match: OpenSSH_5.1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.1
debug1: SSH2 MSGKEXINIT sent
debug1: SSH2 MSGKEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2 MSG_KEX_DH_GEXREQUEST(1024<1024<8192) sent
debug1: expecting SSH2 MSG_KEX_DH_GEXGROUP
debug1: SSH2 MSG_KEX_DH_GEXINIT sent
debug1: expecting SSH2 MSG_KEX_DH_GEXREPLY
debug1: Host '<LOCAL COMPUTER>.local' is known and matches the RSA host key.
debug1: Found key in /Users/<myname>/.ssh/known_hosts:1
debug1: ssh rsaverify: signature correct
debug1: SSH2 MSGNEWKEYS sent
debug1: expecting SSH2 MSGNEWKEYS
debug1: SSH2 MSGNEWKEYS received
debug1: SSH2 MSG_SERVICEREQUEST sent
debug1: SSH2 MSG_SERVICEACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: /Users/<myname>/.ssh/identity
debug1: Offering public key: /Users/<myname>/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Offering public key: /Users/<myname>/.ssh/id_dsa
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: keyboard-interactive
Password:
debug1: Authentications that can continue: publickey,password,keyboard-interactive
Password:
debug1: Authentications that can continue: publickey,password,keyboard-interactive
Password:
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: password
daniel@<LOCAL COMPUTER>.local's password:
Received disconnect from [SOME ID KEY] Too many authentication failures for daniel
[<REMOTE COMPUTER>:~/.ssh] <myname>%

MacbookPro, Mac OS X (10.5.6)

Posted on Apr 30, 2009 9:37 PM

Reply

Answer 1

May 1, 2009 3:56 AM in response to wdchild

From your description I think you placed the public key on the LOCAL computer in the wrong location.

This website shows how to setup public key ssh. The graphic on the top right of the page shows where to place the keys on the server and client.
http://sial.org/howto/openssh/publickey-auth/

Reply

Answer 2

BobHarris

Level 9

56,885 points

May 1, 2009 4:14 AM in response to wdchild

Also check ssh file and directory permissions aganst what is listed in "man ssh".

Reply

Answer 3

wdchild Author

Level 1

0 points

May 1, 2009 7:21 AM in response to Noah Robbin

That is a very good website. Thanks. I will try the instructions there once again.

But as it turns out, I set things up bidirectionally, copying the public key from one computer to authorized keys on the other, and vice versa.

Actually, something else is weird too. Even if the password used for rsa/dsa authentication fails, the optional attempt given at the end of entering the user password should have worked. But it too failed. (And I use this password all the time on both computers, since they are more or less clones of each other. So I definitely didn't get that wrong.) Why would that happen? Could there be confusion from former passwords used the last time I had ssh working (many months ago)? I used to use a different password.

Reply

Answer 4

Tim Haigh

Level 7

24,198 points

May 1, 2009 7:40 AM in response to wdchild

Have you in anyway edited /etc/sshd_config ?

When you say you have already deleted some keys did you touch any of the keys in

/etc/ssh*

?

If you did any of the above you may have broken ssh.

If not the following should fix the problem.

start again from fresh.

delete both ~/.ssh directories on each computer as this will insure the correct permissions are set on each .ssh directory on each computer.

rm -rf ~/.ssh

Then create new DSA keys as they are more secure than RSA keys.

ssh-keygen -b 1024 -t dsa

I usually setup the key without a password this is still very secure.

so just hit enter all the way through the setup.

Then on each machine do

scp ~/.ssh/id_dsa.pub ipaddress_ofotherMac:

replace ipaddress_ofotherMac with the actual IP addresses of each respective mac so if on Mac A put in Mac B's IP address. and when on Mac B put in Mac A's IP address.

Then ssh into the other mac

ssh ipaddress_ofotherMac

cat id_dsa.pub >> ~/.ssh/authorized_keys

Do this from each machine

Then exit out of each mac, and then initiate an ssh connection this should not them prompt you not to enter your macs password.

If you get this far I can show you how to disable password authentication altogether then only public keys will work. This will then allow to open your SSH connection to the internet very securely.

Reply

Answer 5

wdchild Author

Level 1

0 points

May 1, 2009 7:36 PM in response to Tim Haigh

Thanks for explaining that in such detail. If I understand correctly, what you are suggesting is what I already did, with the exception that I did specify a password, and I did not specify a file size for the encryption key (-b 1024). I would like try it again, though, following your instructions exactly, but that is actually not possible. Just to clarify:

When I copied the public key from computer A to authorized keys in computer B, and
the public key from computer B to authorized keys in computer A, I had to do this manually. I cannot scp because I cannot remotely log in in any form. In other words, even without keys, I cannot login (remotely) using my regular (user) password, and I have no idea why. Obviously, I can use the password to log in locally, since I am the administrator on both computers.

What would cause this?

As for the ssh files under etc, I noticed that there are several of them. Someone even suggested once that I modify the sshd_config file, but I opted not to since the settings he was talking about were not even there.

So, if I am going to start afresh, which is what I already tried to do, should I delete the ssh files under etc as well? I noted that you can also have a config file under ~/.ssh/config. Since there are two users for the computer, would that be better?

Reply

Answer 6

BobHarris

Level 9

56,885 points

May 1, 2009 8:56 PM in response to wdchild

What does your ssh command look like? Please provide the verbose one.

In the verbose output I'm seeing 4 password prompts. 3 that look like they want the ssh-keygen passphrase and 1 that wants the daniel account password on the destination Mac..

What passwords did you provide at each password prompt? Not the actual password/passphrase, but whether it was the passphrase for rsa_Id, dsa_id, target system account daniel, or other.

Does the destination system have a daniel account? If no daniel account, that could be the problem.

The only ssh problem I am seeing is not entering the correct password/passphrase when requested.

Reply

Answer 7

Tim Haigh

Level 7

24,198 points

May 2, 2009 7:22 AM in response to wdchild

So, if I am going to start afresh, which is what I already tried to do, should I delete the ssh files under etc as well

No dont touch those just yet.

Check your secure.log to see if that shows up some clues.

On Mac B open the terminal issue the command

sudo tail -f /var/log/secure.log

This will open dynamic view of your secure log which will log your sshd entries.

Then on mac A initiate an SSh login into Mac B. Then check the log to see if that shows you any clues.

Reply

Answer 8

wdchild Author

Level 1

0 points

May 2, 2009 8:46 AM in response to Tim Haigh

Remote login now working. I had two errors. First a dumb one. Wrong user name (no underscore). Second, I think I had the wrong public keys in the wrong version of authorized_keys (blank vs 2). Starting afresh as you suggested, I used only dsa, but I did use a password.

scp seems to work, but I didn't find the file on the other computer, so I copied things the old-fashioned way: using a flash drive. Anyhow, I can now log in to either computer using the dsa key. Thanks to all for the help.

You mentioned password-less login. What would I have to do to get that going?

Reply

Answer 9

BobHarris

Level 9

56,885 points

May 2, 2009 9:20 AM in response to wdchild

Passwordless login. One approach is to use the ssh agent to store your ssh key passphrases in memory. Mac OS X Leopard has an ssh agent already running in the background. I think you can "man ssh-agent" to get more info.

The other approach is when you create ssh-keygen keys you just hit <Return> when asked for a passphrase. These keys will not require a passphrare. Just make sure you do not loose control of your private keys (the half without the .pub).

Reply

Answer 10

Tim Haigh

Level 7

24,198 points

May 2, 2009 2:34 PM in response to wdchild

You mentioned password-less login. What would I have to do to get that going?

to make the key passwordless this is done when you create the key. You would have to make new ones.

the following command would do it

ssh-keygen -b 1024 -t dsa -f id_dsa -P ''

Reply

Answer 11

wdchild Author

Level 1

0 points

May 2, 2009 6:58 PM in response to Tim Haigh

The password-less approach looks easy to set up. Thanks to all of you for so much help. I really appreciate your taking the time.

Reply

Answer 12

Tim Haigh

Level 7

24,198 points

May 2, 2009 7:01 PM in response to wdchild

As this is such a long thread you could have made it easier for other users who search for solutions to identify the posts that were most relevant to solving this issue for you by marking them as helpful or solved.

Have fun with your ssh 🙂

Reply