Could someone help me interpret. This debug

OpenSSH_6.6.1p1, OpenSSL 1.0.1j-freebsd 15 Oct 2014
debug1: Reading configuration data /home//.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to xxxxxx port 22.
debug1: Connection established.
debug1: identity file /home//.ssh/id_rsa type 1
debug1: identity file /home//.ssh/id_rsa-cert type -1
debug1: identity file /home//.ssh/id_dsa type -1
debug1: identity file /home//.ssh/id_dsa-cert type -1
debug1: identity file /home//.ssh/id_ecdsa type -1
debug1: identity file /home//.ssh/id_ecdsa-cert type -1
debug1: identity file /home//.ssh/id_ed25519 type -1
debug1: identity file /home//.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1_hpn13v11 FreeBSD-20140420
debug1: Remote protocol version 2.0, remote software version CoreFTP-0.3.2
debug1: no match: CoreFTP-0.3.2
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEXDH_INIT
debug1: expecting SSH2_MSG_KEXDH_REPLY
debug1: Server host key: RSA xxxxxxxxx
debug1: skipped DNS lookup for numerical hostname
debug1: Host 'xxxxxxxx' is known and matches the RSA host key.
debug1: Found key in /home//.ssh/known_hosts:11
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: password,publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home//.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug1: key_parse_private2: missing begin marker
debug1: read PEM private key done: type RSA
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home//.ssh/id_dsa
debug1: Trying private key: /home//.ssh/id_ecdsa
debug1: Trying private key: /home//.ssh/id_ed25519
debug1: No more authentication methods to try.
Permission denied (publickey).
Connection closed


I don't have direct access to the server but I was given the ssh_config and it does have
'Subsystem sftp /usr/libexec/openssh/sftp-server'

and sshd is running.

Check the permission on your .ssh directory. The files should be readable by the user who is executing the ssh/sftp command.

This looks like an authentication problem more than anything else. Since you didn't mention the command you entered or the rest of the interaction I can't comment on possible causes.

I've tried different variations but sftp x.x.x.x never prompts for a user or password. I tried sftp user@x.x.x.x with the same results


The above was from sftp -v x.x.x.x

The "no match" message in the debug output means that CoreFTP doesn't have any known problems that need work-arounds and can be ignored if there are no other problems.
The real clue is the "missing begin marker" message toward the end of the debug output. This means the begin marker at the beginning of your private key couldn't be found. This suggests that your private key is damaged. It should look like


-----BEGIN RSA PRIVATE KEY-----
<possibly some passphrase info>
<lots of random characters>
-----END RSA PRIVATE KEY-----

(There are a couple of other features you could check but since your key is missing the begin marker you probably have bigger problems.)

Check your key in /home//.ssh/id_rsa and /home//.ssh/id_rsa.pub for correct syntax.

You can check your key using "ssh-keygen -y". This will open your private key (asking for your passphrase) and print the public key to standard out. Compare this with your public key. Something like this should work

ssh-keygen -y -f /home//.ssh/id_rsa

The output of this should match the beginning of the public key in /home//.ssh/id_rsa.pub. There can be extra characters at the end of the key in id_rsa.pub (typically something like user@host).