@natvps_uk said:
Please remove our node IPs from this post.
Never share node IPs publicly!
If this is a policy, it needs to be added to the ToS.
Otherwise, it's merely a suggestion.
"Share publicly" needs to be defined too.
For example, if a customer installs Asterisk telephony server and creates an SRV record pointing to the IPv4+port, the DNS record technically reveals the node IP.
Yeah I’m going to add it, I mean a records are fine. Sharing the IPs on a public forum not so much.
My bad! Everybody wants to avoid what Calin's going through.
Did more testing and it's not just ssh, curl fails too.
Edit: Inbound curl works. Outbound curl (from NL) fails. Didn't want to bug support with a ticket but if it helps I'll get one open
@natvps_uk said:
Please remove our node IPs from this post.
Never share node IPs publicly!
If this is a policy, it needs to be added to the ToS.
Otherwise, it's merely a suggestion.
"Share publicly" needs to be defined too.
For example, if a customer installs Asterisk telephony server and creates an SRV record pointing to the IPv4+port, the DNS record technically reveals the node IP.
Yeah I’m going to add it, I mean a records are fine. Sharing the IPs on a public forum not so much.
My bad! Everybody wants to avoid what Calin's going through.
Did more testing and it's not just ssh, curl fails too.
Edit: Inbound curl works. Outbound curl (from NL) fails. Didn't want to bug support with a ticket but if it helps I'll get one open
SSH from NL to KR now fails rejecting my correct key. Same key works from a third host.
It's as if I'm connecting to a different host, but the ECDSA fingerprint is the same. (retrieved and converted using: dropbearkey -y -f /etc/dropbear/dropbear_ecdsa_host_key | ssh-keygen -l -f - -E sha256)
SSH from NL to CA now fails rejecting correct key
No progress:
SSH from NL to UK fails, no connection
Curl from NL to everywhere still fails
SSH from NL to KR now fails rejecting my correct key. Same key works from a third host.
It's as if I'm connecting to a different host, but the ECDSA fingerprint is the same. (retrieved and converted using: dropbearkey -y -f /etc/dropbear/dropbear_ecdsa_host_key | ssh-keygen -l -f - -E sha256)
SSH from NL to CA now fails rejecting correct key
No progress:
SSH from NL to UK fails, no connection
Curl from NL to everywhere still fails
Interesting, I can’t replicate this on my side.
DM me your Micronode username and I’ll take a look
@yoursunny Just for you we got the SSH keys feature tested today.
Key Management
Provisioning
We're not going to enforce keys immediately and the option for password based auth remains for now. This will be phased out.
It is still down to the client to disable password based login, the way this works currently is a 100 character randomly generated password is set for root - this is never stored and is generated on the node therefore it is never passed in transit either.
Its unlikely that password based login will be removed due to the possibility of community templates using different SSH clients making this fairly tricky although its still very secure using this method.
This will be deployed to production on Thursday AM.
@natvps_uk said: SSH Keys must be in the ssh-rsa format, ssh-dss keys are not supported.
I thought ed25519 algorithm is more modern, isn't it?
You're right, its more modern but not necessarily safer. A 4096 bit RSA key is considered secure.
The reason to go with RSA is down to support, all of our templates support it out of the box and it should simplify the community templates quite a lot.
Dropbear ed25519 support is fairly recent and is not available on all of the distros that we offer meaning that ed25519 support would provide a poor user experience.
Thats not to say that we won't support ed25519 in the future but right now for the initial release RSA is the only supported algorithm.
@natvps_uk said:
The reason to go with RSA is down to support, all of our templates support it out of the box and it should simplify the community templates quite a lot.
Dropbear ed25519 support is fairly recent and is not available on all of the distros that we offer meaning that ed25519 support would provide a poor user experience.
You shouldn't be picky about algorithm.
Just let the user specify contents of authorized_keys file.
Whatever user enters there are automatically uploaded to every new server.
@natvps_uk said:
The reason to go with RSA is down to support, all of our templates support it out of the box and it should simplify the community templates quite a lot.
Dropbear ed25519 support is fairly recent and is not available on all of the distros that we offer meaning that ed25519 support would provide a poor user experience.
You shouldn't be picky about algorithm.
Just let the user specify contents of authorized_keys file.
Whatever user enters there are automatically uploaded to every new server.
So when a user uploads an unsupported key what happens then? They create a support ticket creating unnecessary support and have an overall poor experience or fall back to using password based auth which we are trying to avoid.
We will allow other algorithms going forwards although for this initial release and the foreseeable future we will only be supporting RSA.
@natvps_uk said:
The reason to go with RSA is down to support, all of our templates support it out of the box and it should simplify the community templates quite a lot.
Dropbear ed25519 support is fairly recent and is not available on all of the distros that we offer meaning that ed25519 support would provide a poor user experience.
You shouldn't be picky about algorithm.
Just let the user specify contents of authorized_keys file.
Whatever user enters there are automatically uploaded to every new server.
Yes, long-bit RSA keys are still safe, but ed25519 provides lighter and faster performance (which is unnoticeable in almost every scenario). Since your control panel is a somewhat new one, I though both very stable algorithm and cutting-edge algorithm will be support. It's just like you are supporting mp3 format instead of opus in a new project.
Now that you mentioned ed25519 may be supported in future, I guess it's fine to everyone.
Yoursunny said what I want: users just paste their keys, which the control panel appends to authorized_keys.
@natvps_uk said:
The reason to go with RSA is down to support, all of our templates support it out of the box and it should simplify the community templates quite a lot.
Dropbear ed25519 support is fairly recent and is not available on all of the distros that we offer meaning that ed25519 support would provide a poor user experience.
You shouldn't be picky about algorithm.
Just let the user specify contents of authorized_keys file.
Whatever user enters there are automatically uploaded to every new server.
Yes, long-bit RSA keys are still safe, but ed25519 provides lighter and faster performance (which is unnoticeable in almost every scenario). Since your control panel is a somewhat new one, I though both very stable algorithm and cutting-edge algorithm will be support. It's just like you are supporting mp3 format instead of opus in a new project.
Now that you mentioned ed25519 may be supported in future, I guess it's fine to everyone.
Yoursunny said what I want: users just paste their keys, which the control panel append to authorized_keys.
I get this, and understand both of your points above but RSA is supported on all of our templates, and is supported by most/all distros.
We're going for stability/support rather than cutting edge to provide the best end user experience overall. Once all of our templates support ed25519 we will look to implement it although with the future community templates release we can't guarantee that these templates will support ed25519.
We will add support when possible, if you want to use a ed25519 key its pretty simple, ensure that your ssh server supports it and add it to your authorized keys file.
@natvps_uk said: So when a user uploads an unsupported key what happens then? They create a support ticket creating unnecessary support and have an overall poor experience or fall back to using password based auth which we are trying to avoid.
Well, I believe the omniscient MaxMind will solve that case in the first step.
Oh the above is a joke. Honestly speaking, I don't think it's a problem, because all your service is "unmanaged", so I don't think you should or will offer support in such annoying cases. Plus most your competitors offer "rescue mode" in such case, which the user alone can handle.
@natvps_uk said: We will add support when possible, if you want to use a ed25519 key its pretty simple, ensure that your ssh server supports it and add it to your authorized keys file.
Thanks for explaining.
I think most people have adopted this way:
1. Set root password or paste a public key (if support) when order;
2. log into the system;
3. Config sshd_config to disable password login;
Maybe you should give users a choice to "opt in" for your compulsory key login, if the control panel you bought has that option.
@bliss said: Maybe you should give users a choice to "opt in" for your compulsory key login, if the control panel you bought has that option.
We wrote the control panel in house so additions like this are possible, SSH keys will eventually become compulsory for all instances although there is no planned date for deprecating password based login.
2 major deployments in one day! This one has been requested a lot by our clients.
We have added bandwidth monitoring, we will be adding some dashboards in a future release to allow Micronode users to drill down into their bandwidth usage in a time series graph for both RX and TX.
This new release allows clients to see their combined usage per VPS/Instance.
Please note that whilst it is out of a 1000GB total this is just a guideline and your services will not be suspended if you breach this figure unless you are impacting the network performance for the entire node in which case you will be reminded that network is fair use, usage stats are reset monthly on the 1st of each month.
@natvps_uk said:
2 major deployments in one day! This one has been requested a lot by our clients.
We have added bandwidth monitoring, we will be adding some dashboards in a future release to allow Micronode users to drill down into their bandwidth usage in a time series graph for both RX and TX.
This new release allows clients to see their combined usage per VPS/Instance.
Please note that whilst it is out of a 1000GB total this is just a guideline and your services will not be suspended if you breach this figure unless you are impacting the network performance for the entire node in which case you will be reminded that network is fair use, usage stats are reset monthly on the 1st of each month.
@natvps_uk said:
SSH Key support has been released for instance customers. This will eventually be available for VPS' as well, hopefully in the next release.
SSH Keys must be in the ssh-rsa format, ssh-dss keys are not supported.
It should be fairly self explanatory but documentation will follow.
When creating a new instance and providing SSH Key, will there be an option to have pw auth disabled by default? I believe this was the case with e.g. Lunanode.
@natvps_uk said:
SSH Key support has been released for instance customers. This will eventually be available for VPS' as well, hopefully in the next release.
SSH Keys must be in the ssh-rsa format, ssh-dss keys are not supported.
It should be fairly self explanatory but documentation will follow.
When creating a new instance and providing SSH Key, will there be an option to have pw auth disabled by default? I believe this was the case with e.g. Lunanode.
Not currently:
It is still down to the client to disable password based login, the way this works currently is a 100 character randomly generated password is set for root - this is never stored and is generated on the node therefore it is never passed in transit either.
Its unlikely that password based login will be removed due to the possibility of community templates using different SSH clients making this fairly tricky although its still very secure using this method.
Comments
My bad! Everybody wants to avoid what Calin's going through.
Did more testing and it's not just ssh, curl fails too.
Edit: Inbound curl works. Outbound curl (from NL) fails. Didn't want to bug support with a ticket but if it helps I'll get one open
Please could you try now
A little progress:
SSH from NL to KR now fails rejecting my correct key. Same key works from a third host.
It's as if I'm connecting to a different host, but the ECDSA fingerprint is the same. (retrieved and converted using: dropbearkey -y -f /etc/dropbear/dropbear_ecdsa_host_key | ssh-keygen -l -f - -E sha256)
SSH from NL to CA now fails rejecting correct key
No progress:
SSH from NL to UK fails, no connection
Curl from NL to everywhere still fails
Interesting, I can’t replicate this on my side.
DM me your Micronode username and I’ll take a look
DMed, thanks!
@yoursunny Just for you we got the SSH keys feature tested today.
Key Management
Provisioning
We're not going to enforce keys immediately and the option for password based auth remains for now. This will be phased out.
It is still down to the client to disable password based login, the way this works currently is a 100 character randomly generated password is set for root - this is never stored and is generated on the node therefore it is never passed in transit either.
Its unlikely that password based login will be removed due to the possibility of community templates using different SSH clients making this fairly tricky although its still very secure using this method.
This will be deployed to production on Thursday AM.
Hi @natvps_uk DM'ed you.
https://microlxc.net/
Unfortunately, the payment method is not friendly to China
Works as intended.
Accepting submissions for IPv6 less than /64 Hall of Incompetence.
@natvps_uk Do you mind installing wireguard kernel module on the uk host, which will facilitate wireguard on guest VPS. Thank you.
MicroLXC is lovable. Uptime of C1V
You can use wireguard without the kernel module, I believe there are several releases available that do not require it.
We are not able to install it on the node but somebody here should be able to assist you with the installation.
https://github.com/Nyr/wireguard-install
Wrong thread. Pls delete.
https://microlxc.net/
No not going to do it since you asked for it.
Free Hosting at YetiNode | Cryptid Security | URL Shortener | LaunchVPS | ExtraVM | Host-C | In the Node, or Out of the Loop?
Micronode 1.2.1 Released!
Changelog
Added:
* SSH Key Support
Changed:
* Build process now detects if node is offline.
Fixed:
* Fixed bug causing RO instances to sometimes fail to have network connectivity after deployment.
SSH Key support has been released for instance customers. This will eventually be available for VPS' as well, hopefully in the next release.
SSH Keys must be in the ssh-rsa format, ssh-dss keys are not supported.
It should be fairly self explanatory but documentation will follow.
I thought ed25519 algorithm is more modern, isn't it?
MicroLXC is lovable. Uptime of C1V
You're right, its more modern but not necessarily safer. A 4096 bit RSA key is considered secure.
The reason to go with RSA is down to support, all of our templates support it out of the box and it should simplify the community templates quite a lot.
Dropbear ed25519 support is fairly recent and is not available on all of the distros that we offer meaning that ed25519 support would provide a poor user experience.
Thats not to say that we won't support ed25519 in the future but right now for the initial release RSA is the only supported algorithm.
You shouldn't be picky about algorithm.
Just let the user specify contents of
authorized_keysfile.Whatever user enters there are automatically uploaded to every new server.
Accepting submissions for IPv6 less than /64 Hall of Incompetence.
So when a user uploads an unsupported key what happens then? They create a support ticket creating unnecessary support and have an overall poor experience or fall back to using password based auth which we are trying to avoid.
We will allow other algorithms going forwards although for this initial release and the foreseeable future we will only be supporting RSA.
Yes, long-bit RSA keys are still safe, but ed25519 provides lighter and faster performance (which is unnoticeable in almost every scenario). Since your control panel is a somewhat new one, I though both very stable algorithm and cutting-edge algorithm will be support.
It's just like you are supporting mp3 format instead of opus in a new project.
Now that you mentioned ed25519 may be supported in future, I guess it's fine to everyone.
Yoursunny said what I want: users just paste their keys, which the control panel appends to authorized_keys.
MicroLXC is lovable. Uptime of C1V
I get this, and understand both of your points above but RSA is supported on all of our templates, and is supported by most/all distros.
We're going for stability/support rather than cutting edge to provide the best end user experience overall. Once all of our templates support ed25519 we will look to implement it although with the future community templates release we can't guarantee that these templates will support ed25519.
We will add support when possible, if you want to use a ed25519 key its pretty simple, ensure that your ssh server supports it and add it to your authorized keys file.
Well, I believe the omniscient MaxMind will solve that case in the first step.
Oh the above is a joke. Honestly speaking, I don't think it's a problem, because all your service is "unmanaged", so I don't think you should or will offer support in such annoying cases. Plus most your competitors offer "rescue mode" in such case, which the user alone can handle.
MicroLXC is lovable. Uptime of C1V
Thanks for explaining.
I think most people have adopted this way:
1. Set root password or paste a public key (if support) when order;
2. log into the system;
3. Config sshd_config to disable password login;
Maybe you should give users a choice to "opt in" for your compulsory key login, if the control panel you bought has that option.
MicroLXC is lovable. Uptime of C1V
We wrote the control panel in house so additions like this are possible, SSH keys will eventually become compulsory for all instances although there is no planned date for deprecating password based login.
Micronode 1.2.6 Released!
Changelog
Added:
* Bandwidth Monitorning
Changed:
Fixed:
2 major deployments in one day! This one has been requested a lot by our clients.
We have added bandwidth monitoring, we will be adding some dashboards in a future release to allow Micronode users to drill down into their bandwidth usage in a time series graph for both RX and TX.
This new release allows clients to see their combined usage per VPS/Instance.
Please note that whilst it is out of a 1000GB total this is just a guideline and your services will not be suspended if you breach this figure unless you are impacting the network performance for the entire node in which case you will be reminded that network is fair use, usage stats are reset monthly on the 1st of each month.
This is great. Thank you.
MicroLXC is lovable. Uptime of C1V
When creating a new instance and providing SSH Key, will there be an option to have pw auth disabled by default? I believe this was the case with e.g. Lunanode.
Ympker's VPN LTD Comparison, Uptime.is, Ympker's GitHub.
Not currently: