Thanks CryptoDocker;

Your suggestion isn't silly at all, it's easy to do basic oversights like that, and overcomplicate stuff when troubleshooting.

The main reason why I believe I was hacked was because not only the wallet, but the name of my entire rig, changed. You know when you first set up HiveOS and it appears like "worker" and lists your IP adress? After my rigs stopped mining to my account they would appear under different rig names than my own, always something like "mark3" or mark6". I don't think this would would be the case if its only a matter of the rig going back to the dev's default example mining account? But please correct me if I'm wrong.

Thanks cloudhax!

Believe me, I'd much rather stay with HiveOS rather than change, but I'm tearing my hear out ATM and I'm running out of ideas.

I really appreciate your feedback and suggested solutions, so please allow me to follow up with some questions below:

"my guess is you have your rig wide open to the internet, or some machines on your network are compromised and are using that as a jumping point to get to your rigs."

Could very well be, I have both Mac OS X and Win10 machines on the same LAN/WAN, so I can't rule out what you suggest. All those machines appear to be running like normal (but I realize they could still be compromised), and all have fairly recent OS updates installed with what I assume must be recent security updates.

"even if you had compromised machines, just change the ssh password and remove any existing ssh keys from ~/.ssh/authorized_keys."

I haven't used SSH on any of my machines, at least to my knowledge. (I'm also a linux noob, so this is above my level of technical competence ATM. I have dabbled in Mc OS X terminal and been able to follow detailed instructions describing command line solutions for stubborn OS X problems, but that's about it.)My Mac's have eternal sharing turned off in their Control Panels, which I believe is Apple's GUI name for SSH. I don't know anything about SSH on my HiveOS rigs, as they have been running at default, and I haven't tampered with SSH at all.

"and if you have your rigs open to the internet you need to get them behind a router/firewall that is properly configured and secured".

My rigs are left just as open as my ISP's default router will allow. What goes on in that closed box really isn't documented at all, it's the property of my ISP which is a cable TV company. My rigs are left at HiveOS default settings as far as "open to the internet" applies. So I guess a hardware router/firewall solution could be the answer, but I'm hesitant to throw more money at this problem unless somebody else have had the same problem and can verify that such a solution really fixed it - in which case I'd love to hear more about it in detail, including vendor model, setup details etc.

Advance thanks! :-)

Update: I have to eat humble pie and apologize for even the slightest insinuation that HiveOS could be insecure as per my earlier posts above. It turned out that my undocumented grey cable modem box from the ISP didn't contain even the slightest NAT or firewall functionality, contrary to popular belief in my neighborhood; thus exposing my entire network directly to hackers. After setting up an Asus RT-66U router with NAT and firewall, and after I finished tweaking the rig's OC settings my rigs have now been running without even the slightest hitch for a week, so I'm now in heaven!

Thanks a lot clems, it happened tonight again, always seems to happen at night around 3-4 o'clock, probably so that the hacker can rest assured my rigs will mine for a few hours before I wake up and discover it. Tonight a 3 o'clock my rig was hijacked again and when I woke up it had been renamed "mark 3".

Of all your suggestions this is my status

1. I have already activated 2FA

2 . AFAIK I don't use any port forwarding on my router, but it is a closed ISP router anyway, so AFAIK there's not much I can do with it. So fail2ban is probably my best option.I'm a complete linux noob - could you please explain to me how I can install fail2ban under HiveOS?

3. user default password - I'm not sure which password you mean, but AFAIK I've changed every password, and used pretty secure ones too (long passwords with mix of upper and lower case letters, numbers, symbols etc.)

4. I use only Mac OS X and HiveOS except for my wife's laptop that I've used to flash the memory sticks for HiveOS. I don't think that laptop use antivirus except for the frequent Microsoft updates (Win10).

5. I've used the Nicestats iOS phone app to check on my Nicehash stats, which don't use any HiveOS API keys, but of course it has access to my Nicehash credentials. Using those somebody could probably hijack my Nicehash account before even involving HiveOS. So I believe you may have put me on the right path there. I'll delete that app and change all my Nicehash passwords.

Thanks a lot for your valuable input! :-)

Yes, it is scary and at the same time a bloody nuisance indeed.

I really don't want to think badly about the developer myself; I think he has done an impressive job with every other aspect of HiveOS except for perhaps this one security flaw. I really love the beautiful design and ease of use of HiveOS, and it wouldn't make much sense for the developer(s) to cannibalize subscription revenue by hacking subscribers rigs anyway. Not to speak of all the hard work coding HiveOS potentially going down the drain if HiveOS gets a bad reputation, so that is why I think it is far more likely a matter of a Claymore miner security vulnerability for now. But a security patch within HiveOS would be great, if possible.

Thanks WaveRiderx,

That was exactly what I was thinking - and also what I did - on the first few occasions, but it gets really tedious after a while.

So this last time I just tried a quick fix - "firstrun -f". It didn't work on first attempt, the rig came back under the supposed hackers rig name; "mark3", but I tried once more, and then I was succesful in assigning my own RIG ID, and it has now been succesfully running all night without further incident. I suppose a really advanced hacker could have applied key loggers and thus recorded my passwords etc. and that a clean install would have been safer, but it is also more time consuming, and I didn't have much time last night, but didn't want to lose a whole nights mining revenue, so just attempted the quick fix, thinking I can always do a fresh install and start completely from scratch with new RIG IDs, passwords etc., if it looks like they have been compromised. But so far so good with the quick fix (touch wood).

Maybe I am asking too much, but I think it would be really great if this security vulnerability in HiveOS could be fixed by the developer(s).

I just found a note I made after googling about the security vulnerability in Claymore, and will quote it below - unfortunately I have lost the original URL to the original forum post, but it should be easy enough to find using google if interested in researching more:


One thing I noticed earlier, which may support my theory, is that after one on my rigs crashed earlier, it appeared to come back after the crash with default settings applied - and it seems like Claymore is the default miner if HiveOS is crashing so hard that it can't find the previous rig settings after the crash.

So; that means that if the rig is coming down hard, and defaulting back to Claymore, it will essentially be left vulnerable to Claymore botnet sniffers and hack attacks after every hard crash. I suspect that is what has happened to me - but I could of course be entirely wrong, as I am a mining and linux noob. But it seems to me like a plausible theory for now. If it is correct then it would be great if the HiveOS developer (DimaFern, isn't it?) could patch HiveOS so that the -mport settings recommended for Claymore are automatically applied. It may be very easy to do this for anyone well versed in command line linux, but for complete linux noobs like myself it is too advanced ATM. And it would have to be done after every hard crash; it would be much more secure if it was built into the OS I think. Maybe it could also could be made changes so that Claymore isn't the default miner after a hard crash where previous settings are lost, if Claymore continues to be a security vulnerability.

Hi,

I've used HiveOs for a few weeks now, on and off, as I've been ill lately, but so far I really love everything about the OS except for one thing:

With regular intervals, my rigs suddenly go offline, and rebooting doesn't help, I have to mount a display and check what is going on, and my rigs then appear under other names - "mark3", "mark6" etc. instead of my own rig names.

They also appear to be mining, but not to my own accounts. So I can only assume that I have been hacked, and someone else is taking the profit.

At first I was running Claymore miner, I did a bit of googling and found that there were mentions online of hacking vulnerabilities with that miner, and so I changed to Ethminer, but today it happened again. I managed to get the rig back after forcing "firstrun -f" and entering my own rig credentials again, and I'll see how long that lasts.

After one of the previous incidients, while I was still running Claymore, the rig would just crash immediately after attempting to force "firstrun -f", so the only way to get the rig back online was to flash a new OS on a USB stick, and start over fresh.

I'd really appreciate input from people here about this issue - if anyone else have had similar issues, and if so, what to do to prevent against it.

Advance thanks!

I'm having this problem too, haven't been able to track down the cause. Have tested with 6 1060 cards and two 1070 cards in various combinations and various risers, including different versions and brands, also been doing the "riser dance" and moved the risers around...everything seemingly works like they should, except I can't change any temp or OC settings. I'm also getting console output and everything appears in the web interface, but I can't change OC settings or change the rig group. Or rather, I can change them, but the console reports everything to be like before the change, so the changes obviously don't register with the rig.

I can confirm that I have been partially successful in making the Asus Z270-P work with 6 Palit 1060 cards - with one big caveat - two of the cards, GPU0 and GPU2, are only hashing at half capacity.

The jury is still out on whether I'm having hardware or software issue - or both.

I think I'm having several issues at once, which kind of make it hard to track down. I changed two of the cards from 1070's to 1060's in the hope that managing just one type of cards would simplify things but they didn't. I'm also having issues with SMOS web interface changes not pushing through to the rig - it remains stuck on the same algo/currency/pool even though I try to change the rig group to something else, and the OC and Watt settings have no effect. But the strange thing is that the rig reboots after changing the settings, just as if it was restarting because of the changes - but everything remains the same when inspecting the console. This seems like a SMOS issue, but I can't be sure.

The two GPU' s running at half speed could be a nicehash related issue, as some googling around have revealed that people have had issues with this when mining to nicehash. Easiest thing to do would be to change to another pool to see if that made a difference, but then SMOS is refusing to push pool setting changes through, leaving me stuvk with nicehash ATM. Bit of a catch 22.

I was thinking I'd try Pimp OS as soon as I have a little spare time just to see how that affects things, but ATM I don't have much spare time...

My console reports all cards set to 115 watts even though most of them are set to 75,75,75,75,115,155 in OC settings. Any clues? Temps are running way too high currrently and none of my OC changes push through. Help - anyone?

Am I the only one having/had issues with settings not taking effect through the web interface? No matter what I try to do the mining rig is stuck at the same group settings (even though I change group to other pool etc. in other group settings that worked previously) and OC changes make no difference and deleting the rig and restarting so it reappears as noname doesn't improve anything.

Pretty much useless at this point except for the fact that it is still mining at an old pool, but delivering far from optimal revenue ATM so I want to change it, also teps are too high so I want to change OC/temp settings but they take no effect. Help, anyone?

Ok, so now I tried to switch Rig Groups for the miner as well as try to edit the OC settings, and THAT didn't stick either. So no matter what I do the settings don't register with the mining rig.  I've already deleted the rig once and that didn't make any difference. Any suggestions please...?

edit: I should add that the correct group is reflected in the web interface, but the rig is clearly running the previous mining pool etc. when viewing the console.

Thanks - yes, I've seen that mentioned several places and it has not been lost on me, both core and mem populated :-) Still no percieveable changes wether I OC or not, it seems like the OC settings somehow don't register at all...?

I have the same issue, and tried to delete the rig as per Radu's advice, and it popped back up as a noname rig afterwards, but it didn't fix the OC issue. No matter what I do it seems the Core/Mem and temperature are stuck. Anyone have any other suggestions - please?

Thanks Radu!

I've made the following adjustments in the OC settings:

Core MHz: 150,150,150,150,-50,-50

Memory MHz:600,600,600,600,1150,1150

Power Limit (watt):70,70,70,70,98,98

Target Temperature ℃:65
Minimum Fan speed %:50

The Core/Mem column in the RigList says this, which is why I have assumed the two last cards are the 1070's (even though I'm a bit pussled by the lower numbers for those cards here, but as they stand out as a pair I'm assuming that's them there):

1961 1974 1949 1961 1797 1771 (70,70,70,70,98,98)
4100 4100 4100 4100 4100 4100

I'm still getting pretty much the same results in the console as previously:

========== Sol/s: 1736.8 Sol/W: 2.57 Avg: 1750.4 I/s: 935.9 Sh: 12.41 1.00 51
GPU0 64C Sol/s: 204.5 Sol/W: 1.78 Avg: 204.5 I/s: 109.8 Sh: 1.47 1.00 52
GPU1 74C Sol/s: 332.6 Sol/W: 2.86 Avg: 327.9 I/s: 176.1 Sh: 2.04 1.00 67
GPU3 74C Sol/s: 333.7 Sol/W: 2.85 Avg: 327.1 I/s: 174.7 Sh: 2.04 1.00 46
GPU2 75C Sol/s: 154.2 Sol/W: 1.32 Avg: 151.2 I/s: 80.9 Sh: 0.94 1.00 41
GPU4 73C Sol/s: 274.3 Sol/W: 2.68 Avg: 290.4 I/s: 148.4 Sh: 2.30 1.00 55
GPU5 65C Sol/s: 447.1 Sol/W: 3.92 Avg: 449.3 I/s: 241.6 Sh: 3.46 1.00 67
========== Sol/s: 1746.4 Sol/W: 2.57 Avg: 1750.3 I/s: 931.6 Sh: 12.25 1.00 54
> GPU0 65C Sol/s: 204.0 Sol/W: 1.78 Avg: 204.5 I/s: 109.8 Sh: 1.54 1.00 67
> GPU1 74C Sol/s: 326.5 Sol/W: 2.86 Avg: 327.9 I/s: 176.2 Sh: 2.00 1.00 67
> GPU3 74C Sol/s: 324.5 Sol/W: 2.85 Avg: 327.0 I/s: 174.7 Sh: 2.11 1.00 57
> GPU2 75C Sol/s: 151.4 Sol/W: 1.32 Avg: 151.2 I/s: 80.9 Sh: 0.98 1.00 47
> GPU4 74C Sol/s: 281.9 Sol/W: 2.68 Avg: 290.2 I/s: 151.7 Sh: 2.26 1.00 55
> GPU5 66C Sol/s: 449.1 Sol/W: 3.92 Avg: 449.3 I/s: 241.4 Sh: 3.50 1.00 57
========== Sol/s: 1737.5 Sol/W: 2.57 Avg: 1750.1 I/s: 934.8 Sh: 12.39 1.00 58

So, what am I missing here - pretty please....? :-)

Thanks a lot Radu!

When inserting the individual comma-separated OC settings, do the settings correspond to the GPU's listed numbers (as in GPU0, GPU1, GPU2etc.) or the listed order from top to bottom in the console (as in GPU3, GPU4, GPU2 in the example I provided earlier?) - or is there some other logic to it? :-)

Again - many thanks, much appreciated! :-)

Hi all,

I got my first rig up and running a couple of days ago, and have noticed that the different GPU's are reporting very different speeds in the console, here's a typical excerpt:

========== Sol/s: 1729.1 Sol/W: 2.57 Avg: 1754.6 I/s: 933.9 Sh: 7.26 0.99 50
GPU3 75C Sol/s: 327.6 Sol/W: 2.84 Avg: 326.5 I/s: 174.9 Sh: 1.33 0.99 55
GPU4 75C Sol/s: 295.6 Sol/W: 2.71 Avg: 296.4 I/s: 155.2 Sh: 1.17 1.00 44
GPU2 75C Sol/s: 150.3 Sol/W: 1.32 Avg: 151.4 I/s: 81.1 Sh: 0.66 0.98 43
GPU0 74C Sol/s: 205.2 Sol/W: 1.78 Avg: 204.0 I/s: 109.1 Sh: 0.86 0.99 48
GPU1 75C Sol/s: 333.5 Sol/W: 2.86 Avg: 328.2 I/s: 175.7 Sh: 1.39 0.99 50
GPU5 76C Sol/s: 443.1 Sol/W: 3.91 Avg: 448.1 I/s: 239.3 Sh: 1.84 1.00 43
========== Sol/s: 1755.4 Sol/W: 2.57 Avg: 1754.6 I/s: 935.2 Sh: 7.26 0.99 47
GPU3 74C Sol/s: 325.5 Sol/W: 2.84 Avg: 326.5 I/s: 174.9 Sh: 1.33 0.99 55
GPU4 75C Sol/s: 292.5 Sol/W: 2.71 Avg: 296.4 I/s: 156.6 Sh: 1.17 1.00 54
GPU2 75C Sol/s: 150.4 Sol/W: 1.32 Avg: 151.4 I/s: 81.2 Sh: 0.66 0.98 60
GPU0 74C Sol/s: 209.0 Sol/W: 1.78 Avg: 204.0 I/s: 109.1 Sh: 0.86 0.99 48
GPU1 75C Sol/s: 324.0 Sol/W: 2.86 Avg: 328.2 I/s: 175.8 Sh: 1.39 0.99 51
GPU5 75C Sol/s: 437.8 Sol/W: 3.91 Avg: 448.1 I/s: 239.3 Sh: 1.83 1.00 43
========== Sol/s: 1739.1 Sol/W: 2.57 Avg: 1754.6 I/s: 936.9 Sh: 7.26 0.99 51

The rig is still a work in progress as I'm waiting for parts, but it is currently running four Palit 1060 6GB cards and two Palit 1070 OC cards. It seems like two of the cards, GPU2 and GPU0, are seriously underperforming at 150-200 Sol/s, so I'd really appreciate all advice and pointers in the right direction for the best way to improve this.

My OC settings in SMOS are currently set to this, based on recommendations in the SMOS guidelines:

Core MHz: 150

Memory MHz: 600

Power Limit (watt): 115

Target Temperature ℃: 70
Minimum Fan speed %: 50

I'm not sure if I understand correctly how OC'ing works yet, but I've seen mention of making individual OC'ing settings, like "140, 150, 130..." etc. - am I supposed to do this to tweak each individual card to it's max efficiency?

I did one attempt at setting up such a comma-separated string and saved the settings, and the miner restarted, but I did get pretty much the same results in the console, so that's why I feel very much in doubt about the right direction ahead.

All advice would be very much appreciated - advance thanks! :-)