cannot log into Ubuntu 16.04 server with ssh keys

April 3, 2017 905 views
Security Ubuntu 16.04

I have completed the tutorials for initial setup of the Ubuntu 16.04 server, LAMP, and Secure Apache with Let's Encrypt. I was able to log in one time. After I lost my connection through bad wifi my terminal froze. I closed the terminal and could not log back in.

ssh: connect to host hostname.org -p port: Connection timed out

I enabled a pass phrase, but it doesn't ask it. What could be wrong?

1 comment
  • I haved logged into the server with the panel and reviewed the changes I made, but don't know which setting could be causing the issue. The host name is givechildrenbooks.org, port is 5069.

5 Answers

What is the hostname and port?

You can access the server if you log into the control panel in DigitalOcean and use the Console.

It's hard to say what went wrong, but my first guess would be either firewall or you changed the default port 22 of SSH.
Which tutorial did you use specifically? And did you do anything outside the scope of the tutorial?

Have you already changed your DNS to point to your server - otherwise continue to use the IP address.

  • I've already changed the DNS. You can see the site, givechildrenbooks.org

    I followed everything save one option. When running ssh-keygen it asks:

    Enter file in which to save the key (/Users/localuser/.ssh/id_rsa):
    

    Instead of going with the default I typed "books". I didn't see any indication that it saved that file name. The contents of the .ssh folder is idrsa, idrsa.pub, and known_hosts.

    • This path /Users/localuser/.ssh/id_rsa looks like MacOS paths.
      But it shouldn't have anything to do with SSH stops working.

      Can you insert the link to the tutorial you followed?

@technicallyblue
Make sure the file /etc/ssh/sshd_config has the line Port 5069 and reboot the server after the change.
It seems like you've added a firewall rule to block port 22 - at least that's what I'm seeing when scanning your server:

22/tcp  closed ssh

Remember to click "Reply" under the post or use the @ sign to notify people - otherwise we might miss a message from you.

  • I will have to run sudo ufw app list to check this correct? I cannot use the console where I'm at right now. Can do this in a few hours. Thanks

    • I think it's just sudo ufw list

      • sudo ufw list just gives ufw options.
        sudo ufw app list gave:
        Available applications:
        Apache
        Apache Full
        Apache Secure
        OpenSSH

        /etc/ssh/sshd_config has Port 5069 listed

        • Try this instead:

          sudo ufw status numbered
          

          Also run this:

          lsof -iTCP -sTCP:LISTEN -P
          
          • ufw status numbered retured:
            1 OpenSSH ALLOW IN Anywhere
            2 Apache Full ALLOW IN Anywhere
            3 OpenSSH (v6) ALLOW IN Anywhere
            4 Apache Full (v6) ALLOW IN Anywhere

            lsof -iTCP -sTCP:LISTEN -P didn't return anything

@technicallyblue We've maxed out the other thread, so starting a new.
Sorry, run this again, because I specifically used to "numbered" to avoid getting the canonical names:

sudo ufw status numbered

And then run this:

sudo lsof -iTCP -sTCP:LISTEN -P
  • ufw status numbered retured:
    1 OpenSSH ALLOW IN Anywhere
    2 Apache Full ALLOW IN Anywhere
    3 OpenSSH (v6) ALLOW IN Anywhere
    4 Apache Full (v6) ALLOW IN Anywhere

    lsof -iTCP -sTCP:LISTEN -P didn't return anything

    • Have you restarted your server? And you're using Ubuntu 16.04 right?

      It makes no sense. We should get a numbered list back from UFW and LSOF should list at least Apache, MySQL, SSH.

    • @technicallyblue Can you just try to disable UFW as a test:

      sudo ufw disable
      

      And then let's see if SSH is working.

@technicallyblue

I would recommend simply shutting down the firewall service using Console and see if that allows you to log back in via SSH. You can do that by running:

ufw disable

If you're able to login with ufw disabled, then your IP was most likely blocked. Normally, I recommend using actual ports over defined services when setting up ufw. Using actual ports seems to be far less problematic.

So if you're able to login with ufw disabled, I'd now run a reset to wipe all existing rules.

ufw reset

You now have a clean slate from which to work from. So let's rebuild.

We'll start with default rules. We'll deny all incoming and allow outgoing. These rules won't matter as right now, ufw is disabled, so you shouldn't get locked out when running them if you ran both of the commands above.

ufw default deny incoming
ufw default allow outgoing

Now we need to specify which ports to allow in. I always start with SSH since that's the first thing I'll be using and it's the most important to start with.

Now, from the looks of it, you're using another port -- from what I've read, that's 5069, though let's confirm that to make sure so that you don't end up getting locked out again.

Please run:

grep "Port" /etc/ssh/sshd_config

You'll see a port echo'ed out to the screen that looks like Port ... where ... is the port. If that says 22, then we'll use 22. If it says 5069, then use that.

So let's allow SSH. As above, change 22 to the other port if that's what's showing in your SSH config.

ufw allow 22/tcp

Now since you're using Apache and LetsEncrypt, we need to allow HTTP and HTTPS connections, and we can do that by allowing ports 80 and 443 through.

ufw allow 80/tcp
ufw allow 443/tcp

At this point, unless you need to allow additional ports through, we can go ahead and start ufw back up and let it resume.

ufw enable

You'll get a warning that you may be kicked, but as long as you used the correct SSH port in the above command, you'll be fine.

Hopefully that helps to get you back in :).

  • This helped me narrow it down perfectly. Even though ssh was listening on 5069, I didn't allow that port through the firewall. Would have been nice to get "denied" instead of "timed out"

    ufw allow 5069/tcp and ufw enable did the trick!

    Thanks for the help!

    • @technicallyblue

      No problem at all, happy to help :-).

      The reason you're seeing a timeout is most likely due to not having default policies in place (as I noted at the top of my previous reply). If you do the reset and then follow the above, it should begin denying instead of just allowing a connection to sit idle and then timeout.

      That's why I always recommend a reset first, then setting up the deny/allow first.

Have another answer? Share your knowledge.