Hello!
I was playing around on the Meteohub this morning and looked at the log files, and it turns out that someone was trying to bruteforce my Meteohub!
I moved the SSH port to a non-standard port, but I was wondering if there was a way to turn off SSH via the web interface. I know there is a status on the main page when you log in.
If it's not already there, then this should definitely be in the Whishes section, but that would be handy because I do need SSH access, but not all of the time.
Way to turn off SSH via web interface?
Moderator: Mattk
Re:Way to turn off SSH via web interface?
I'd be very concerned about turning it off entirely - I've twice had bugs crop up on my flash drive that blocked the web interface from starting up. If I'd not been able to use SSH, I would have had to do a clean reinstall of the system, wiping everything on the drive.
Re:Way to turn off SSH via web interface?
Errr, I understand and agree, but I was unnerved by someone trying to bruteforce it. Maybe a 3-incorrect password timeout or something?
Re:Way to turn off SSH via web interface?
Well, one approach could be to set up public-key-only authentication, so that the password involved is only processed on your machine, to decrypt the private key. So that means there's no actual password attached to the account, only to your private key, thus nothing for an attacker to guess at.
However, that can be daunting for the uninitiated, so here's a couple other possibilities:
sshd_config:
PermitRootLogin: no - this means that you'd have to log in as a normal user first, then switch to root - no way to log in to the system directly as root. If the attacker was going after the root password, this would block him by forcing him to guess a username, then the password for that username, then the root password.
Along the same lines, you could also add a second root account with a secret username - as long as the user has a UID of zero:
root:x:0:0:Root:/:/bin/bash
... it will behave exactly the same way as the root account. You can then disable the password of the real "root" account. You'd want to keep it in place, because some things, like the crontabs, can be tied to the "root" username and you'd break that if you simply changed the username. Application installer scripts might also expect to find a "root" username to update cron jobs and other things.
HostbasedAuthentication: yes - this means that only hosts listed in /etc/hosts.equiv will be allowed to log in - you'd put the Meteohub's idea of your hostname into /etc/hosts.equiv and then only that host would be allowed.
Careful, though - test it before completely disconnecting your root session, otherwise if you have a typo in the /etc/hosts.equiv you'd be locked out, or if the hostname is being retrieved from an unexpected place. Also, I'd add more than just one machine as allowed, just in case water spills on your PC.
Likewise, watch out for DHCP IP address changes, since if your Windows machine gets a different IP, it won't match the /etc/hosts.equiv anymore. Make your Windows machine's DHCP reservation static to get around this.
However, that can be daunting for the uninitiated, so here's a couple other possibilities:
sshd_config:
PermitRootLogin: no - this means that you'd have to log in as a normal user first, then switch to root - no way to log in to the system directly as root. If the attacker was going after the root password, this would block him by forcing him to guess a username, then the password for that username, then the root password.
Along the same lines, you could also add a second root account with a secret username - as long as the user has a UID of zero:
root:x:0:0:Root:/:/bin/bash
... it will behave exactly the same way as the root account. You can then disable the password of the real "root" account. You'd want to keep it in place, because some things, like the crontabs, can be tied to the "root" username and you'd break that if you simply changed the username. Application installer scripts might also expect to find a "root" username to update cron jobs and other things.
HostbasedAuthentication: yes - this means that only hosts listed in /etc/hosts.equiv will be allowed to log in - you'd put the Meteohub's idea of your hostname into /etc/hosts.equiv and then only that host would be allowed.
Careful, though - test it before completely disconnecting your root session, otherwise if you have a typo in the /etc/hosts.equiv you'd be locked out, or if the hostname is being retrieved from an unexpected place. Also, I'd add more than just one machine as allowed, just in case water spills on your PC.
Likewise, watch out for DHCP IP address changes, since if your Windows machine gets a different IP, it won't match the /etc/hosts.equiv anymore. Make your Windows machine's DHCP reservation static to get around this.
Re: Re:Way to turn off SSH via web interface?
Is there someone who tested this? What are the consequences of disabling the password OR changing it? Are there any processes dependent on the root password?mvpel wrote: Along the same lines, you could also add a second root account with a secret username - as long as the user has a UID of zero:
root:x:0:0:Root:/:/bin/bash
... it will behave exactly the same way as the root account. You can then disable the password of the real "root" account. You'd want to keep it in place, because some things, like the crontabs, can be tied to the "root" username and you'd break that if you simply changed the username. Application installer scripts might also expect to find a "root" username to update cron jobs and other things.
My problem is like many other posts: The need to backup a remote meteohub server via the internet.
Solution:
1. Use SSH with a second root account with a totally different password That works.
2. Change SSH port. Have to use that also as the isp blocks all normal ports, that works fine now.
3. RSA authentication so no hacker can use brute force password guessing. Works fine after so many hours of googling etc. Having a Mac which has to pull the data from a meteohub/linux was not that easy documented.
Question: I assume i can disable the password of the second root account also when using RSA. Have to test that next week.
3. Use a command file executed every so many seconds on my mac at home to rSync the meteohub to my in house computer. Works fine.
I opened and closed ssh only for short period of time to test but still there those hackers detected an open port and tried to get inside.
So before really opening the new ssh port i have to be sure that NO internal meteohub process uses the root password whatsoever. I don't want to hurry to the other site to restart meteohub after a hacker got inside.
Next week this backup process goes live so if anyone knows a flaw please let me know.
Another remark:
When i tried to set this option thinking that RSA is not really a " Login " the connection process died.PermitRootLogin: no - this means that you'd have to log in as a normal user first, then switch to root
I did not put that many effort in finding out why happened.