All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Microtronix...
I am trying to test this service for backups, got the storage package activated, got the emails with the host, the username and the password, but I cannot execute any commands via SSH, not even ls or mkdir to create a directory where to store my backups.
I always get
/etc/ssh/sshrc: 3: [: -eq: unexpected operator
You are not permitted to execute this command.
Contact the systems administrator for further assistance.
I contacted them, and the first thing they asked me was my password so they could test. LOL
Then I logged in the control panel, which is Usermin, and I found that there was already a key added to the authorized_keys file, which was not mine. I removed it, added mine, and it doesn't work. SSH asks for the password anyway.
I have looked around and it doesn't look very trustworthy as service. Who is using them here?


Comments
This was their response about the key I found in my account:
Amazing. I'm glad it was just 2 bucks. To anyone using this provider and cares about security, think twice before renewing with them.
What provider?
They will colo your ex for the right money.
I cancelled the package, they shut down my account and refunded the two bucks
They replied to the ticket, but my account was closed so I cannot see it.
https://www.microtronixdc.com/
@jfreak53 any comments?
From product description:
In https://www.microtronixdc.com/products/backup-storage
I see
SSH Accessible (Jailed CHRoot), rSync, FTP, Duplicity. I would be surprised if they didn't allow simple commands like ls and mkdir and I guess they would have told me if these were not possible. It doesn't make much sense IMO.In the email I also see
SSH (SCP, SFTP, rSync, etc.) Port: 22and no mention that simple commands like these are forbidden.Yeah I had no problem using Filezilla when I had the account for couple months. However I had issues with Paypal billing, the payment wasn't registered and recurring payments didn't work either. Spent too much time in tickets sorting out for just $2/m and eventually due to failing automatic payment got my service deleted.
Your user was created the exact same way all other users were created, same way, we checked folder permissions, you own it, so on our side we can't see anything wrong with your user or account. No other user has the error you have, so seems its your program or user error. Simple commands are accessible, yes, its a simple chroot shell, its more than likely the way you are connecting or the program you are using.
The next logical step is to test SSH access using your user as you do, to rule out the program you are using or user error. You have not been able to use it yet, so nothing should be there, simply change your password and send that to us we asked, we test, if ssh works for us it means its your program or user error. If you refuse to provide a temporary password there is nothing we can do to further test.
The key issue there is no way for us to prove or disprove that key exists, or prove or disprove you didn't create this key yourself without us snooping into your folder. Our system doesn't create keys when we create user folders, which means it didn't come from us, our skeleton folder for new users doesn't even have an SSH folder in it. Potentially usermin created it automatically for you and your user. Again, we don't snoop on customers files, so there was no way to prove or disprove your claims without your permission.
We asked for your password to a brand new account to test further, you refused, so we can't do anything else. This actually proves our loyalty and trustworthiness since being its not a VPS and just a CHRoot environment we could of just
su'd into the user, or we could of just reset your password ourselves, we didn't, we asked.Finally, you refused, so without you even asking I refunded you your money, deleted your files and account, you got your money back, and could move on. No harm no foul.
Here is the ticket for everyone to see, if you refuse to provide password for us to test ourselves there is nothing else we can do, your user had permissions and is brand new, so either you broke something in your user folder or your program was causing the error. If you refuse to go the next step what do you expect from us, magic?
Its $2 that even got refunded before you asked for one, move on
https://ibb.co/m5HsmpDd
https://ibb.co/Hp137CCF
I was using plain SSH, nothing else. I was trying to create a directory for Restic backups. No other programs etc.
As for the key "prove or disprove" - I didn't create any key myself before seeing that one. And your response,
is plain ridiculous and enough for me to never trust you as provider. And even the
shows that you don't know your own service well.
No prob
glad you got your $2 back and can find another provider. Bless you and have a great and awesome day 
summerhost behavior
Microtronix is prem!
Hi,
i have no idea of nothing here, but technically having file access via ssh != having shell access via ssh.
So while you could do fileoperations via ftp or scp, issuing shell commands might naturally not work with jailed environments.
LOL, if you are happy with it, good for you
You shouldn't connect over ssh as remote console, mount it as sftp folder and backup to your mount. You could use rclone for mount.
They sponsor us a dedi for freevps.org, and it's been pretty much flawless for 2 years now. How can we not be happy?
wtf?
From the screenshot it clearly shows that this 'You are not permitted to run' is triggered even before running
ls. It's sshrc (or you client environment calling something else?) flow. You didn't even tried to look into /etc/ssh/sshrc and that "syntax" error?I don't understand. One day you are pentester getting mad bounty money for finding critical shit other day you can't even check why there is an syntax error in bash script?
How do you want provider to debug your problem if you are not willing to give them password?
@jfreak53 just for lulz wanna drop
/etc/ssh/sshrccontent?My random guess it's
shvsbashas shell or even vito client tries to forcezshbecause he hacker and forgot that he enabled it globally and does not work on that restricted jailed ssh?I may have misunderstood the restrictions, fine, but that's not the point. The provider's response to the presence of a key I didn't create, that's the point.
This is actually what most people do, we use our own backup servers for our own company as well as our customers, our MSP division uses our backup servers for our customers. So we trust the security and how our servers work enough to not only use it for our stuff, but our MSP customers as well for that division of the company. This is how we use it ourselves.
It does run shell commands, basic ones, as it has a bin and etc folder for chroot, its entirely possible he deleted the bin folder which would cause this issue since he'd no longer have programs to run. But without seeing inside his user folder we couldn't say, and we don't snoop, soooooo.
I didn't delete any folder, and I am not stupid enough to delete a bin folder and think it's OK. You on the other hand, told me that you didn't know why a key would already be in my authorized_keys and told me to "just delete the thing".
I also tried the service. I used FTP for my backups. I used SSH from the control panel (Usermin) using Terminal. I used it for a few months, then stopped because it didn't meet my requirements:
I switched to another provider that did have a public folder.
Sure why not haha. This error usually happens when someone tries to run inline SSH commands, rsync will complain about it but it moves on and does its job just fine, since we use rsync. But the command not found error usually means they deleted their bin folder, which is why I wanted his user access, once he gives us password it means we have permission to test SSH from his user and also go into his user folder to see if the bin folder is there and if there are any customizations they made that might cause it. Without that password we don't have permission soooo haha.
https://cdn.microtronix-tech.com/imgs/Screenshot_at_2025-11-21_10-45-29.jpg
https://cdn.microtronix-tech.com/imgs/Screenshot_at_2025-11-21_10-47-24.jpg
I mean you clearly fucked up using
/bin/shin shebang when you are actually usingbashsyntax with[ -eq ].Duh.
But yeah, could be /bin gone (and you have that set to bash) so it shit itself.
or some other client setting changing $PATH and breaking things.
Ex no, too much drama, no one needs that in their lives come on now. Mother in law, probably, but not ex
This line:
for sure points to a coding issue on their server. The problem may be triggered by some client configuration, but it is caused by them. If they just look at sshrc line 3 and they are competent, they will see the mistake. I cannot tell you the exact problem because I cannot see sshrc line 3, but it's their server so they can see it. They're probably using a variable without quotation marks and that variable is empty when you connect, but not empty in most configurations.
So to answer your question, yes there is a syntax error but it doesn't stop a user from logging in over ssh, want me to record a video to show you so you can see that ssh does indeed work?
Besides sshrc line 3 I posted above, so it is there to look at. Either way, SSH works, rSync works, SFTP works, many customers use it daily. If this customer would of simply worked with us to fully test and diagnose the issue he would have his backup space now.
Not sure why it's not clear yet, so I will try one more time. The problem I have with you as provider and the reason why I cancelled and would never use you is NOT really the fact that I was unable to run basic commands. I could have definitely worked with you on that, no problem at all with that. The problem I have with you as provider is in your answer to my question about a key I found in the authorized_keys file for my account (using the Usermin control panel). You literally told me you didn't know why there would be an unexpected key in there, and to just delete it. A more serious provider would have been less lazy and would have seen this as enough to raise an alarm and start a proper investigation. For sure, it's enough of a red flag for me to never try your services again.
Do you see the problem now?