I have the same trace in my logs and I disabled the key for the moment. For a quick translation because the page is in French:
If you have a server with OVH, they setup by default a secondary SSH key in /root/.ssh/authorized_keys2 which is allowed to access your server only from a single IPv4 and a single IPv6. This is to allow debugging of your server.
It looks like the private key has been compromised and is now used to try to access the servers from another IP. Your server will not be compromised, but by security, better to disable this extra key by renaming the file "authorized_keys2.disabled".
You can check your logs with a grep like this:
# grep "correct" /var/log/auth.log
Jul 17 21:42:49 node1 sshd[18548]: Authentication tried for root with correct \
key but not from a permitted host (host=178.63.21.XXX, ip=178.63.21.XXX).
I was introduced to OVH when they had a promotion where they gave 100 kimsufi servers away (free for a year). I was really impressed with the prices that they were selling real hardware at (and still do).
However, I have grown a great distaste to them in the last few years, namely because of this behaviour and it's implications; when I buy a dedicated server that I am going to manage myself it would be nice to at least have the option to install a clean distribution and not have to go the extra mile of bootstraping.
That's the only reason you've found so far? That's pretty good.
They have much worse things in place:- their anti-dos measures make it near impossible to put anything of value on their without a LOT of work. For example, once they detect a DoS (just 50 Mbps was enough but it varies) they will take down your server (not just its IP) for 4-12 hours at a time.
With that said, there are some great things about OVH: they drive down the costs and make everything quite efficient (e.g., hardware prices, support costs) but then seem to just forget that they need to reduce the costs for the customer as well (their anti-dos measures being an example of how they increase the cost).
I wonder if that DOS policy will be the same for the new North America data center. I have a beta server with them and am enjoying their service but taking someone's service offline for a small scale DOS attack may be a game changer.
It probably won't change. Their US routers do not appear to be any different to the EU ones (e.g., they both intentionally rate limit ping to them so you'll see a lot of timeouts).
No it does not, it's only when you ping their edge routers do you see packet loss, they still pass all traffic (and thus ping) over them just fine. You can see this in traceroutes or running mtr.
I believe (not 100% sure) they put their anti-dos on these routers which is why I think the US servers will have the same anti-dos measures.
Have you tried asking them? I do not believe they would hide this fact (it would be interesting to know whether they mark it as a selling point or not).
We are aware of this and are currently investigating it. Our initial thoughts were that it was indeed a compromise but after further review it seems that this is actually a bug with Debian and certain versions of RedHat.
We've tested it with different keys and have suffered the same results. I'll let you know if anything changes and we'll be announcing this shortly.
Thank you in any case, but rest assured it's not a serious issue.
The information is wrong, and OVH was right. I hereby apology for the mistake. See this for more details. FS#7060 — Debian: log d'authentification SSH incorrect. http://travaux.ovh.net/?do=details&id=7060&edit=yep
21 comments
[ 4.4 ms ] story [ 67.1 ms ] threadIf you have a server with OVH, they setup by default a secondary SSH key in /root/.ssh/authorized_keys2 which is allowed to access your server only from a single IPv4 and a single IPv6. This is to allow debugging of your server.
It looks like the private key has been compromised and is now used to try to access the servers from another IP. Your server will not be compromised, but by security, better to disable this extra key by renaming the file "authorized_keys2.disabled".
You can check your logs with a grep like this:
Actually only from a single IPv4 (cache.ovh.net). The IPv6 address is the equivalent IPv4 mapped to IPv6 (::ffff: prefix).
OVH pre-install a number of things by default on their Debian image including monitoring software (it integrates into their manager) and this key.
The only way to make sure things like this are a non-issue is to do a clean install yourself, e.g., via debootstrap in "rescue pro mode".
You can then install the key on their request if required giving you more control.
However, I have grown a great distaste to them in the last few years, namely because of this behaviour and it's implications; when I buy a dedicated server that I am going to manage myself it would be nice to at least have the option to install a clean distribution and not have to go the extra mile of bootstraping.
They have much worse things in place:- their anti-dos measures make it near impossible to put anything of value on their without a LOT of work. For example, once they detect a DoS (just 50 Mbps was enough but it varies) they will take down your server (not just its IP) for 4-12 hours at a time.
With that said, there are some great things about OVH: they drive down the costs and make everything quite efficient (e.g., hardware prices, support costs) but then seem to just forget that they need to reduce the costs for the customer as well (their anti-dos measures being an example of how they increase the cost).
I believe (not 100% sure) they put their anti-dos on these routers which is why I think the US servers will have the same anti-dos measures.
Have you tried asking them? I do not believe they would hide this fact (it would be interesting to know whether they mark it as a selling point or not).
We are aware of this and are currently investigating it. Our initial thoughts were that it was indeed a compromise but after further review it seems that this is actually a bug with Debian and certain versions of RedHat.
We've tested it with different keys and have suffered the same results. I'll let you know if anything changes and we'll be announcing this shortly.
Thank you in any case, but rest assured it's not a serious issue.
If there is a "from" filter on a key in case of failure this message appear even if the key don't match.
The information is wrong, and OVH was right. I hereby apology for the mistake. See this for more details. FS#7060 — Debian: log d'authentification SSH incorrect. http://travaux.ovh.net/?do=details&id=7060&edit=yep