0

So today my Server got hacked. But just a non sudoer user.

Nov 26 10:44:18 Ubuntu-1604-xenial-64-minimal sshd[27188]: Accepted publickey for ... from hackerIP port 26394 ssh2: RSA SHA256:...

He started a screen and scanned networks nothing more. History is empty. He connected with some publickey tho I never added any keys. I know I should use ssh-keys instead of password. But my root never got compromised. What I noticed in auth.log is this

Nov 26 19:01:01 Ubuntu-1604-xenial-64-minimal CRON[12360]: pam_unix(cron:session): session opened for user ... by (uid=0)
Nov 26 19:01:01 Ubuntu-1604-xenial-64-minimal CRON[12360]: pam_unix(cron:session): session closed for user ...
Nov 26 19:02:01 Ubuntu-1604-xenial-64-minimal CRON[12368]: pam_unix(cron:session): session opened for user ... by (uid=0)
Nov 26 19:02:01 Ubuntu-1604-xenial-64-minimal CRON[12368]: pam_unix(cron:session): session closed for user ...

I do not know if I am posting it in the wrong section to be honest. I basically just want to know where to find the ssh-keys because my key folder is empty. How to disable remote login for that specific user (so that I only can connect over root and use 'su' command to login). And what to do with pam_unix.

Edit: Firtsly thanks for the huge help. I could undone everything the attacker did. And I disabled ssh-key login in sshd config so only passwords are valid. Failed2Ban is running as well and I am managing auth.log everyday manually.

  • The keys would be in the compromised user's home folder, ie /home/baduser/.ssh. – user508889 Nov 26 '16 at 18:29
  • The second log snippet is the periodic command scheduler cron executing something. Look at everything in all /etc/cron.* as well as /etc/crontab and everything in /var/spool/cron/crontabs. (Assuming here for a second that Ubuntu is like Debian in this regard, which it probably is.) – a CVn Nov 26 '16 at 19:18
  • @bc2946088 i checked every user folder including the compromised one every single one was empty. probably he deleted the key? – Tom-Oliver Heidel Nov 26 '16 at 21:32
  • @MichaelKjörling yeah I found that cronjob. and could stop that. – Tom-Oliver Heidel Nov 26 '16 at 21:33
3

If you want to disable a user from being able to remote into SSH, you have a couple configuration options directly from /etc/ssh/sshd_config.

I personally favor using whitelists instead of blacklists for user accounts. Here is why, using a whitelist only allows the explicit users to login where a blacklist, only prevents those users. The whitelist is more complete in my opinion.

If you wanted admin, joe, and sally to remotely connect using SSH, the following directive added to /etc/ssh/sshd_config would work.

AllowUsers admin joe sally

If you simply wanted to block baduser from connecting, use the following.

DenyUsers baduser

Either option, you need to sudo service ssh restart for the changes to take affect.

|improve this answer|||||
  • No need to restart, reload is sufficient. – fkraiem Nov 26 '16 at 18:42
  • I much prefer working with groups instead of users. Create a group ssh-in (or whatever you want to call it), then add AllowGroups ssh-in to sshd_config, then add the relevant users to it (using vigr or usermod --append --groups ssh-in $USERNAME) – a CVn Nov 26 '16 at 19:03
  • That a slick way of doing it, @MichaelKjörling. I don't have users on my systems other than myself, but if I did, I could see this being really beneficial. – user508889 Nov 26 '16 at 19:14
  • @bc2946088 I'm willing to bet that you have plenty of users on your system other than yourself, but perhaps not human users. Even a clean Ubuntu installation (like almost every other Linux distribution out there possibly short of Linux From Scratch) sets up a number of service accounts. Granted those often don't have any valid password configured, but you never know... – a CVn Nov 26 '16 at 19:16
  • Of course, though I simply whitelist my own user in ssh. To create a group and add myself and still edit the configuration to whitelist the group would be additional steps with no seen benefit. @MichaelKjörling – user508889 Nov 26 '16 at 19:22
1

Authorized keys are almost always in ~/.ssh/authorized_keys for the particular user. You can find their home directory by doing the command cd ~username The authorized keys file location can be changed in the /etc/ssh/sshd_config with a line like with AuthorizedKeysFile /some/path/to/authorized_keys_file so I would check both places.

You can disable login to that user by adding something like the following to your /etc/ssh/sshd_config:

AllowUsers root user

to only allow specific users or

DenyUsers user1 user2

to deny specific users. There's a lot of other cool stuff like this, just read the sshd_config man page.

Usually root is not the account you want to ssh into because if it get's compromised, they can do anything.

Lastly, about the pam_unix thing, it's a cronjob. You can find cronjobs in:

/var/spool/cron/crontabs
/etc/crontab
/etc/cron.d
/etc/cron.hourly
/etc/cron.daily
/etc/cron.weekly
/etc/cron.monthly
|improve this answer|||||
0

To harden your sshd config,

Disable login/passwd login : in /etc/ssh/sshd_config

ChallengeResponseAuthentication no
UsePAM no

And you should disable root login (use sudo)

PermitRootLogin no

Ans as said by Bryce, use AllowUsers (but not root ;-)

There are some config you can do.

|improve this answer|||||
  • I am just curious about to turn off Pam since I do not really know what it does. I read something about two-factor auth and stuff and password checking. I will read man page tomorrow. But appreciate if someone can shortly sum up the important things. – Tom-Oliver Heidel Nov 26 '16 at 21:38
  • PAM check login/passwd, so if you do not create a specific PAM config for ssh, PAM will alow login/passwd login. So to disable login/passwd login, you have to disable PAM during the ssh login sequence. – f35 Nov 26 '16 at 21:58

Not the answer you're looking for? Browse other questions tagged or ask your own question.