Can't SSH to Dokku

Hi @sjm,

Sorry for the second reply!

Alternatively, if you are having issues with ``Git push dokku master``` returning permission denied, you can check the following Question that was posted in our community

https://www.digitalocean.com/community/questions/git-push-dokku-master-is-returning-permission-denied

The answer that’s pinned could help you as well.

Regards, KFSys

Hi @sjm,

As far as I understand, you can’t SSH to your droplet, is that correct?

First, let’s start with something simple just to make sure everything is correct before going into the deep waters. Enter your droplet via DigitalOcean’s WebConsole and see what’s in your /root/.ssh/known_hosts file. Do you see your public SSH key? If not, add it and try to SSH one more time.

If this fails you can go over the below.

Usually, when you use SSH, the automatic keys that are being used are id_rsa.pub and id_rsa. In order for you to make them take another .pub file you can use the -i option:

ssh -i /path/to/id_rsa(digitalocean.pub) user@XXX.XXX.XXX.XXX

Try with that one.

Additionally, I can see you are using it on a user that’s different with root. It’s possible somewhere something hasn’t been configured properly like wrong permissions, ownerships, stuff like that.

Let’s first being with the usual stuff:

• Your home directory ~, your ~/.ssh directory and the ~/.ssh/authorized_keys file on the remote machine must be writable only by you: rwx------ and rwxr-xr-x are fine, but rwxrwx--- is no good, even if you are the only user in your group (if you prefer numeric modes: 700 or 755, not 775).
• If ~/.ssh or authorized_keys is a symbolic link, the canonical path (with symbolic links expanded) is checked.
• Your ~/.ssh/authorized_keys file (on the remote machine) must be readable (at least 400), but you’ll need it to be also writable (600) if you will add any more keys to it.
• Your private key file (on the local machine) must be readable and writable only by you: rw-------, i.e. 600.

Now that we’ve passed the standard stuff, let’s get going on the more interesting stuff.

When you run

/usr/sbin/sshd -d -p 2222

On your droplet, you can then connect without a password, what does the debug information says on your droplet, It should state something like

Authentication allowed

In this case, what you can do is temporarily stop the SSH daemon and replace it with one in debug mode. Don’t worry, stopping the SSH daemon won’t kill any existing connections. This means it’s possible to run this without being connected to the droplet’s Console but it’s somewhat risky. If the connection does get broken for any kind of reason, you’ll need to connect using your droplet’s console. Anyway, you can run the following

service ssh stop
/usr/sbin/sshd -d
#...debug output...
service ssh start

If it again runs with the debug mode being on, then for sure it’s the SELinux causing the issues, it’s most probably set to Enforcing. The .ssh dir will probably be mislabeled. Look at /var/log/audit/audit.log. Check with ls -laZ and then Run restorecon -r -v /path/to/users/.ssh.

Regards, KFSys