Can't do outgoing SSH

Question

Level 1

20 points

Can't do outgoing SSH

I'm really frustrated and imagine I'm doing something wrong.

I've been trying to SSH into a remote server (hosted on godaddy.com) from my Mac. I can FTP into it just fine, but SSH always fails with "Permission Denied". The server uses the same username/password for FTP and SSH so I know it is correct. I have talked to the Godaddy people who confirmed that everything was set up correctly on their end. So what am I doing wrong?

Here's what I'm doing on my Mac:

- Launch Terminal

- Type "ssh -l username domain.suffix" (obviously with my actual username and domain name/suffix)

(I have also tried "ssh username@domain.suffix")

When prompted for the password, I enter it

It fails every time with Permission Denied.

I am far from an expert on this stuff, am I missing a step? I've read some stuff about needing to modify files in the .ssh directory but I'm not sure this applies to me. I'm not trying to ssh IN to my Mac, just trying to ssh OUT to the web server.

I haven't done anything fancy with public and private keys.

Help!

iMac i3 Core 3.2 GHz, Mac OS X (10.6.8)

Posted on Aug 2, 2011 8:21 PM

Reply

Answer 1

etresoft

Level 8

46,602 points

Aug 2, 2011 8:37 PM in response to DaviatorSF

Ssh is very picky about directories. It does use the .ssh directory even if you are just doing outgoing connections. Make sure your home directory permissions are no more lax than "drwxr-xr-x". Make sure your .ssh directory permissions are "drwx------". It will need to write the "known_hosts" file in .ssh regardless, so it needs to be able to do that. I suggest going ahead and setting up a public key with "ssh-keygen -t dsa". Make sure to provide a passphrase. Keychain Assistant can manage that for you.

Once you have all of that setup, try ssh again. If it still doesn't work, try "ssh -v" or even "ssh -v -v" for more detail.

Eventually you will want to use a public key and stop using FTP. That will be a task for later.

Reply

Answer 2

Linc Davis

Level 10

209,547 points

Aug 2, 2011 8:37 PM in response to DaviatorSF

Post the output of this:

ssh -vvv username@domain.suffix

Reply

Answer 3

DaviatorSF Author

Level 1

20 points

Aug 2, 2011 9:03 PM in response to Linc Davis

I will go look at all the directory permissions (thanks for the suggestion.) In the meanwhile, here's the result of the ssh -vvv:

OpenSSH_5.2p1, OpenSSL 0.9.8r 8 Feb 2011

debug1: Reading configuration data /etc/ssh_config

debug2: ssh_connect: needpriv 0

debug1: Connecting to dtna.org [72.167.232.144] port 22.

debug1: Connection established.

debug1: identity file /Users/xxxxx/.ssh/identity type -1

debug3: Not a RSA1 key file /Users/xxxxx/.ssh/id_rsa.

debug2: key_type_from_name: unknown key type '-----BEGIN'

debug3: key_read: missing keytype

debug2: key_type_from_name: unknown key type 'Proc-Type:'

debug3: key_read: missing keytype

debug2: key_type_from_name: unknown key type 'DEK-Info:'

debug3: key_read: missing keytype

debug3: key_read: missing whitespace

debug2: key_type_from_name: unknown key type '-----END'

debug3: key_read: missing keytype

debug1: identity file /Users/xxxx/.ssh/id_rsa type 1

debug1: identity file /Users/xxxxx/.ssh/id_dsa type -1

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.2

debug2: fd 3 setting O_NONBLOCK

debug1: SSH2_MSG_KEXINIT sent

debug1: SSH2_MSG_KEXINIT received

debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie- hellman-group14-sha1,diffie-hellman-group1-sha1

debug2: kex_parse_kexinit: ssh-rsa,ssh-dss

debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blow fish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,xxxxx@lysator.liu.se

debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96

debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib

debug2: kex_parse_kexinit:

debug2: kex_parse_kexinit: first_kex_follows 0

debug2: kex_parse_kexinit: reserved 0

debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie- hellman-group14-sha1,diffie-hellman-group1-sha1

debug2: kex_parse_kexinit: ssh-rsa,ssh-dss

debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes1 92-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr

debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96

debug2: kex_parse_kexinit: none,zlib@openssh.com

debug2: kex_parse_kexinit:

debug2: kex_parse_kexinit: first_kex_follows 0

debug2: kex_parse_kexinit: reserved 0

debug2: mac_setup: found hmac-md5

debug1: kex: server->client aes128-ctr hmac-md5 none

debug2: mac_setup: found hmac-md5

debug1: kex: client->server aes128-ctr hmac-md5 none

debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent

debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP

debug2: dh_gen_key: priv key bits set: 114/256

debug2: bits set: 500/1024

debug1: SSH2_MSG_KEX_DH_GEX_INIT sent

debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY

debug3: check_host_in_hostfile: filename /Users/dtroup/.ssh/known_hosts

debug3: check_host_in_hostfile: match line 2

debug3: check_host_in_hostfile: filename /Users/dtroup/.ssh/known_hosts

debug3: check_host_in_hostfile: match line 2

debug1: Host 'dtna.org' is known and matches the RSA host key.

debug1: Found key in /Users/dtroup/.ssh/known_hosts:2

debug2: bits set: 509/1024

debug1: ssh_rsa_verify: signature correct

debug2: kex_derive_keys

debug2: set_newkeys: mode 1

debug1: SSH2_MSG_NEWKEYS sent

debug1: expecting SSH2_MSG_NEWKEYS

debug2: set_newkeys: mode 0

debug1: SSH2_MSG_NEWKEYS received

debug1: SSH2_MSG_SERVICE_REQUEST sent

debug2: service_accept: ssh-userauth

debug1: SSH2_MSG_SERVICE_ACCEPT received

debug2: key: /Users/xxxx/.ssh/identity (0x0)

debug2: key: /Users/xxxx/.ssh/id_rsa (0x100123fa0)

debug2: key: /Users/xxxxx/.ssh/id_dsa (0x0)

debug1: Authentications that can continue: publickey,password,keyboard-interactive

debug3: start over, passed a different list publickey,password,keyboard-interactive

debug3: preferred publickey,keyboard-interactive,password

debug3: authmethod_lookup publickey

debug3: remaining preferred: keyboard-interactive,password

debug3: authmethod_is_enabled publickey

debug1: Next authentication method: publickey

debug1: Trying private key: /Users/xxxx/.ssh/identity

debug3: no such identity: /Users/xxxx/.ssh/identity

debug1: Offering public key: /Users/xxxx/.ssh/id_rsa

debug3: send_pubkey_test

debug2: we sent a publickey packet, wait for reply

debug1: Authentications that can continue: publickey,password,keyboard-interactive

debug1: Trying private key: /Users/xxxx/.ssh/id_dsa

debug3: no such identity: /Users/xxxx/.ssh/id_dsa

debug2: we did not send a packet, disable method

debug3: authmethod_lookup keyboard-interactive

debug3: remaining preferred: password

debug3: authmethod_is_enabled keyboard-interactive

debug1: Next authentication method: keyboard-interactive

debug2: userauth_kbdint

debug2: we sent a keyboard-interactive packet, wait for reply

debug1: Authentications that can continue: publickey,password,keyboard-interactive

debug3: userauth_kbdint: disable: no info_req_seen

debug2: we did not send a packet, disable method

debug3: authmethod_lookup password

debug3: remaining preferred:

debug3: authmethod_is_enabled password

debug1: Next authentication method: password

xxx@xxxx's password:

debug3: packet_send2: adding 48 (len 68 padlen 12 extra_pad 64)

debug2: we sent a password packet, wait for reply

debug1: Authentications that can continue: publickey,password,keyboard-interactive

Permission denied, please try again.

< Edited by Host >

Reply

Answer 4

etresoft

Level 8

46,602 points

Aug 2, 2011 9:04 PM in response to DaviatorSF

That sure looks like the wrong password.

You do have an RSA public key. You could FTP that up to the .ssh/authorized_keys directory on the remote system. I suspect someone at GoDaddy may not understand ssh and hasn't given you all the information. If they are still using FTP, that wouldn't be surprising.

Reply

Answer 5

DaviatorSF Author

Level 1

20 points

Aug 2, 2011 9:17 PM in response to etresoft

I checked all the permissions and set them appropriately but it didn't change anything.

I'm positive it's the right password... I've reset it several times to no avail (and it works fine for FTP, and all of their documentation (and their support rep) says that the SSH and FTP passwords are the same.

Yes, I created an RSA key earlier (forgot about that) but haven't done anything else with it. I'll try copying that file up to the directory you recommend and see if that makes any difference.

But it sounds like you are confirming that what I am doing SHOULD work and if it doesn't, something is going on at the server-side?

Much thanks for the help!

Reply

Answer 6

Linc Davis

Level 10

209,547 points

Aug 2, 2011 9:19 PM in response to DaviatorSF

I don't think it's a wrong password. The server or the remote account is misconfigured. Maybe the SSH daemon hasn't been configured to allow that user to log in, or maybe the user's shell or home directory is invalid.

Reply

Answer 7

etresoft

Level 8

46,602 points

Aug 3, 2011 5:46 AM in response to DaviatorSF

That is correct. Everything you are doing should work. It could be a misconfiguration or restriction on the server side. I gave GoDaddy the benefit of the doubt because they told you it should work. SSH is usually part of a more expensive hosting package.

Reply

Answer 8

BobHarris

Level 9

53,273 points

Aug 3, 2011 6:37 AM in response to DaviatorSF

If you copy your id_rsa.pub file to your GoDaddy account, you store that public key in your .ssh/authorized_keys file.

And on the GoDaddy account, the permissions on your home directory and the .ssh directory are critical, as ssh will not use a public key if it thinks anyone can modify your home directory or the contents of your .ssh directory.

If you can get another ssh session that work (another server, another Mac, anything), the best thing to do is capture the successfully ssh -vvv output and compare that to the failed GoDaddy ssh -vvv output. That will often times highlight where the failing connection attempt goes wrong.

Reply

Answer 9

DaviatorSF Author

Level 1

20 points

Aug 4, 2011 12:58 AM in response to etresoft

Thanks to all of you for the help. I went back to Godaddy (again...) and this time they did indeed find and fix some sort of problem on their end – and I am now able to ssh successfully. So I was doing everything right, but they had convinced me that the problem must be on my end (it wasn't.)

Now I'll work on getting the RSA key to work. 🙂

Thanks again!

Reply