Changes to NatVPS

15791011

Comments

  • edited February 2023

    @natvps_uk said:

    @yoursunny said:

    @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_uknatvps_uk Hosting Provider

    @ruets said:

    @natvps_uk said:

    @yoursunny said:

    @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

    Please could you try now

  • edited February 2023

    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

  • natvps_uknatvps_uk Hosting Provider

    @ruets said:

    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

    Thanked by (1)ruets
  • @natvps_uk said:

    Interesting, I can’t replicate this on my side.

    DM me your Micronode username and I’ll take a look

    DMed, thanks!

  • natvps_uknatvps_uk Hosting Provider

    @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.

  • Unfortunately, the payment method is not friendly to China B)

  • @Clan said:
    Unfortunately, the payment method is not friendly to China B)

    Works as intended.

    Thanked by (2)Clan beanman109

    Webhosting24 aff best VPS; ServerFactory aff best VDS; Cloudie best ASN; Huel aff best brotein.

  • edited February 2023

    @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.

  • natvps_uknatvps_uk Hosting Provider

    @bliss said:
    @natvps_uk Do you mind installing wireguard kernel module on the uk host, which will facilitate wireguard on guest VPS. Thank you.

    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.

  • @natvps_uk said: somebody here should be able to assist you with the installation

    https://github.com/Nyr/wireguard-install

    Thanked by (3)natvps_uk Ympker bliss
  • edited February 2023

    Wrong thread. Pls delete.

  • @Fritz said:
    Wrong thread. Pls delete.

    No not going to do it since you asked for it. :p

    Thanked by (1)Fritz

    "I would have gotten away with it too, if it wasn't for that meddling Frankz and Mason!!"

  • natvps_uknatvps_uk Hosting Provider

    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.

    Thanked by (2)Ympker benz
  • natvps_uknatvps_uk Hosting Provider

    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.

  • @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?

    Thanked by (1)yoursunny

    MicroLXC is lovable.

  • natvps_uknatvps_uk Hosting Provider

    @bliss said:

    @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.

    Webhosting24 aff best VPS; ServerFactory aff best VDS; Cloudie best ASN; Huel aff best brotein.

  • natvps_uknatvps_uk Hosting Provider

    @yoursunny said:

    @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.

  • edited February 2023

    @yoursunny said:

    @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.

    MicroLXC is lovable.

  • natvps_uknatvps_uk Hosting Provider

    @bliss said:

    @yoursunny said:

    @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.

    MicroLXC is lovable.

  • @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.

    MicroLXC is lovable.

  • natvps_uknatvps_uk Hosting Provider

    @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.

    Thanked by (1)bliss
  • natvps_uknatvps_uk Hosting Provider
    edited February 2023

    Micronode 1.2.6 Released!

    Changelog

    Added:
    * Bandwidth Monitorning
    Changed:
    Fixed:

    Thanked by (2)bliss go626201
  • natvps_uknatvps_uk Hosting Provider

    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.

    Thanked by (4)bliss SeederKun go626201 bdl
  • @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.

    This is great. Thank you.

    Thanked by (1)natvps_uk

    MicroLXC is lovable.

  • YmpkerYmpker OGContent Writer
    edited February 2023

    @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_uknatvps_uk Hosting Provider

    @Ympker said:

    @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.

    Thanked by (1)Ympker
Sign In or Register to comment.