5

I'm running a basic Ubuntu server from Digital Ocean, which I use an SSH key (stored on my Desktop) to access.

I've just run netstat -ap with the following result:

Local Address     Foreign Address        State        PID
XX.XXX.XX.192  183.214.141.105:53929   ESTABLISHED 25193/sshd: root [p 

This isn't me, I've searched the IP and it's under a number of banned lists and originates from China.

My Questions:

1) As the state is 'ESTABLISHED', does that mean they have access to my server via SSH? Or is this brute force attempts to gain entry?

2) How could my server of been compromised? I'm not aware brute force can work on SSH keys? Wouldn't they have to access my key on my Desktop?

  • 1
    Established doesn't mean they are logged in. The information of who logged in when is available in /var/log/auth.log (or other log files on other distributions). – FACTORY909 Feb 16 '17 at 20:59
  • 4
    The cut off word at the end is `[preauth]`. – Michael Hampton Feb 16 '17 at 21:04
  • 2
    Have a look at /var/log/auth.log. If you're really compromised it's not safe to assume the log is correct, but if you're not you can see the login attempts and probably the failures. To secure yourself, use ssh with key-only login and fail2ban. Changing the SSH-Port to some higher port prevents almost all automated bots away, too. – allo Feb 16 '17 at 22:20
  • 2
    Preauth means they have not yet authenticated. In order for the serverside process to change uid to the authenticated user it must run as root. Ssh worms continue to bounce around the internet, there are lots of things you can do to limit your exposure. – symcbean Feb 16 '17 at 23:54

1 Answers1

13

1) Established only means that the connection is fully open and data can be transmitted. It doesn't necessarily mean that any data has been transmitted! It doesn't imply anything about layer 7, whether someone has authenticated to your system or not. You can check your system logs to learn if someone has authenticated successfully. (source)

2) Maybe. You are going to need to check your logs and see if someone has authenticated successfully. On Ubuntu, ssh logs can be found in /var/log/auth

https://unix.stackexchange.com/questions/127432/logging-ssh-access-attempts

Don't forget that you can bruteforce the passphrase of an ssh key.

On a side note, rebuilding a private key from a public one is technically currently impossible

https://security.stackexchange.com/questions/33238/brute-forcing-ssh-keys

I would recommend to use some two factor authentication with ssh and Fail2ban

Fail2ban scans log files (e.g. /var/log/apache/error_log) and bans IPs that show the malicious signs -- too many password failures

Tolsadus
  • 1,123
  • 11
  • 22
  • 1
    good answer. Also I will add to check who is currently logged in you can type the command `w` – gbolo Feb 17 '17 at 00:13
  • 2
    None of the reputable answers to the linked question suggest that brute-forcing ssh keys is possible; rather than it's not. If you're using 2FA with ssh, it's not a precaution against brute-force but against having your key stolen. Fail2ban is not useful on ssh unless you have passwords enabled. – R.. GitHub STOP HELPING ICE Feb 17 '17 at 03:13
  • @R.. You can always ban people that keeps failing to auth themselves with a wrong ssh key. http://serverfault.com/questions/153617/is-fail2ban-safe-better-to-use-ssh-keys – Tolsadus Feb 17 '17 at 06:31
  • @Tolsadus: No, you can only ban ip addresses/address blocks from which failed authentication attempts come. This does not ban people, but might end up banning yourself, e.g. if an attacker on the same cellular network with thousands of devices NAT'd behind the same ip address hits you with (useless) brute force attempts. – R.. GitHub STOP HELPING ICE Feb 17 '17 at 17:35
  • You can realistically attack the password encryption of an OpenSSH privatekey file, if it has a human-memorable (i.e. not really strong) password and doesn't use the new-since-6.5 format with a strong PBKDF -- but ONLY IF you _have_ a copy of the privatekey file, which an evil-maid or border-guard class attacker does but a remote-net-only attacker like this one does not. – dave_thompson_085 Feb 19 '17 at 19:04