One place for hosting & domains

      Remote

      Preparing Your Corporate Network for Emergency Remote Work: Bandwidth, VPNs, Security and Notes for INAP Customers


      The global spread of the novel coronavirus (COVID-19) has organizations large and small readying their office-based staff for temporary remote work. While it’s a wise move for achieving containment, this isn’t as easy as an email sending everyone home for two weeks. Many infrastructure and networking considerations must be accounted and planned for, not the least of which is additional bandwidth to ensure steady application performance.

      In a snap poll by Gartner, 54 percent of HR leaders indicated that poor technology and/or infrastructure for remote working is the biggest barrier to an effective work from home model. IT leaders play an essential role in abating that concern and making any telework policy a success.

      With that in mind, what are the top networking and security considerations for remote work?

      Check out the brief network FAQ below for the most essential points.

      How can I determine if my company needs additional bandwidth?

      Start by looking at your applications. What applications do workers need to effectively do their jobs? How and how often are these applications accessed?

      Good news: If the application is already hosted in the cloud via platform as a service (PaaS) or software as a service (SaaS), you may not have an issue. Workers using Office 365, for example, will still be able to access their important documents and communicate effectively with their teammates via related workflow tools like Microsoft Teams. But even if an application isn’t in the cloud, if workers are on a remote desktop program, the heavy lifting is done in the data center and won’t affect your network.

      Additional bandwidth may be needed if your organization runs frequently used, resource-hungry applications over the corporate network. Common examples are file share systems or home-grown apps that involve rich media or large data sets, like CAD software or business intelligence tools. Access to these will require a VPN, which in turn may require greater bandwidth. (See below) The net amount of new bandwidth needed will be determined by application access and traffic patterns.

      What considerations need to be made to support a greater number of VPN users?

      First, review your license capacity. VPNs are typically licensed per concurrent user. For example, an organization might choose a license for 50 users because the number of remote workers at one time would rarely if ever exceed the cap. With emergency plans, however, that number might suddenly jump to 250.

      Next, look at hardware specs. Firewalls have different capacities for hardware performance. They also have a hard number of users than be supported from a VPN. Check with your VPN provider to make adjustments.

      There are also hardware limits for how many users a VPN can handle. For instance, a new firewall license may be needed if your current limits are insufficient. To update the license, you would need to make a call to your firewall provider to update the number of seats.

      What recommendations should companies make for worker’s home connections?

      The biggest roadblock to smooth remote network connectivity may be largely outside IT’s control: Your end user’s home internet service. In this case, preparation is key. Before a mass migration to remote work, test a representative sample of current remote users’ access to applications to see where you might run into performance bottlenecks. If some employees don’t have access to high-speed internet, discuss business continuity contingencies with senior leadership. Can the company reimburse users for upgrades? If not, how can critical work be done offline?

      What security measures should be considered with sizeable move to remote work?

      While the VPN will provide a secure connection, two-factor authentication ensures the remote users are who they say they are. You should also configure your system to prohibit file storage on users’ home devices, and if possible, prevent VPN access to employees’ home devices altogether by providing company owned endpoints.

      For optimal network security, configure your VPN to prevent split tunneling, which allows for some traffic to route over the protected network and other traffic (such as streaming and web browsing) through the public internet. While this will make all endpoints more secure, preventing split tunneling will require more bandwidth.

      I’m an INAP customer and need more bandwidth. What’s the process?

      If you’re a current INAP customer and already have bandwidth with us, you can check your IP usage here. If needed, you can adjust your commit or your cap limit, depending on how your circuit is set up. Increasing your commits is easy as long as there are no physical changes being made.

      If you have a cap configuration, changes to the rate limit are also simple to make via a logical configuration. While you can remove the cap or increasing the rate limit, be cautioned that this isn’t the most fiscally beneficial move to make, as making a commit will get you a better price.

      If you need to change the physical network topology, such as making a move from a 1 GB to a 10 GB circuit, the process will take additional time. Contact INAP support or your account rep to start the discussion.

      Finally, if you’re an INAP Colocation customer and won’t be able to directly manage your environment at the data center, contact us for adding 24/7 remote hands support.

      I’m looking for a new high-performance bandwidth service. How can I get started?

      Our multi-homed bandwidth service, Performance IP®, is powered by our proprietary route optimization engine, which ensures your outbound traffic reaches end users along the lowest latency path.

      If you’re already collocated in one of INAP’s 100 Global POPs, the turnaround for a cross connect is typically achieved in 1-2 weeks. If a remote connection to your data center is required, contact us for a complimentary solution design consultation.

      Click here to check out our locations or chat now to get started.

      Interested in learning more?

      CHAT NOW

       

      Contributor: Paul Just, INAP Solution Engineer

      Laura Vietmeyer


      READ MORE



      Source link

      How To Use Visual Studio Code for Remote Development via the Remote-SSH Plugin


      Introduction

      Visual Studio Code is a popular Integrated Developer Environment (IDE) for developers. Its large selection of plugins, minimal design, and cross-platform support make it a great choice for developers of all levels. This tutorial focuses on using the Remote-SSH plugin to enable remote software development. With this plugin you can edit files on your local workstation, but run development tasks such as program execution, unit tests, or static analysis on a remote server.

      There are many reasons why this may be beneficial to you. For example, you may have a Windows workstation and want to develop on Windows, but your code will eventually run on Linux. You may need more RAM or processing power than your current machine has available, or you want to keep code off of your personal machine due to a company policy, or the desire to keep your workstation prestine.

      In this tutorial, you’ll enable the Remote-SSH plugin, configure Visual Studio Code to execute code on the remote server, and execute code from your local Visual Studio Code installation on the remote server.

      Prerequisites

      In order to follow along with this guide, you’ll need:

      • A local development machine running Windows, MacOSX, or Linux. This tutorial will not work on ChromeOS devices.
      • Visual Studio Code, which you can download and install from the official web site.
      • An SSH key pair generated:
      • One Ubuntu 18.04 server set up by following the Ubuntu 18.04 initial server setup guide, including a non-root sudo-enabled user and a firewall.

      Step 1 — Installing the Remote-SSH Plugin

      The Extensions Marketplace is where you can download supported and third-party extensions for a variety of different tools and programming languages. This is where you will search for the Remote-SSH plugin and install it.

      On the left-hand side of the IDE there is a vertical row of five icons. The bottom icon, which looks like four squares in a box with the top right square exploding out, is the icon for the Extensions Marketplace:

      Extensions Marketplace Icon Location

      You can also access this section by pressing Ctrl+Shift+X. When you open this page you will see suggested plugins to download and install.

      Once you have the Extensions Marketplace open, type Remote-SSH in the Search Extensions in Marketplace search bar. When you find the plugin, select it and then click the green Install button to install the extension.

      Search for the Remote SSH Plugin

      The extension is now installed. Next, you’ll configure the extension so you can connect to your server.

      Step 2 — Configuring the Remote-SSH Plugin and Connecting To Your Server

      Now that you have the plugin installed you can configure it to connect to a server. To do so, you’ll need the following pieces of information:

      • The server’s IP or hostname.
      • The username you’ll connect with.
      • The private key you’ll use to authenticate your user.

      You’ll use this information to create an SSH configuration file that Visual Studio Code can use to SSH to the server to sync files and execute code on your behalf. You will create this configuration using Visual Studio Code.

      Now that you have the Remote-SSH plugin installed, you’ll see a small green box in the bottom left-hand corner of the Visual Studio Code interface. If you hover over the box with your mouse pointer, the popup will say Open a remote window. The button looks like a greater than sign slightly under a less than sign ><, like the one in the following image:

      Open a remote window green UI button

      Click the button, and a dialog box appears in the top center. Select Remote-SSH: Open Configuration File… from the list:

      Selecting Configure SSH in the UI

      The next prompt will ask you which configuration file you want to open. If you’re on Windows, you’ll see two locations: one in your personal user directory, and one in the installation location for SSH. You should use the file in your user directory when configuring the server.

      Select the file and your editor will open the config file. Add the following code to the file to define the connection to your server, replacing the highlighted sections with the information for your server:

      config

      Host my_remote_server
          HostName your_server_ip_or_hostname
          User sammy
          IdentityFile /location/of/your/private/key
      

      Here’s how this configuration file works:

      • Host: This specifies a name for your host. This lets you use a short name or abbreviation instead of the full IP address or host name when connecting to the server.
      • HostName: The actual hostname of the server, which is either an IP address or a fully qualified domain name.
      • User: The user you want to use to connect with.
      • IdentityFile: The path to your SSH private key. On Mac and Linux systems, you’ll find this in your home directory in a hidden .ssh directory, typically called id_rsa. If you are on Windows you will have specified a location to save this file when you created it using putty-gen.

      Specify the appropriate values in your file and save the file.

      Visual Studio Code is now configured and ready to connect to your server. Click on the green Open a remote window button in the bottom left-hand corner and select Remote-SSH: Connect to Host…

      Connecting to the Server from Visual Studio Code

      Once you’ve done this all the availble and configured servers will appear in the dropdown menu. Select the server that you want to connect to from this list.

      If this is the first time you have connected to this server from your machine, you’ll likely be prompted with the SSH Fingerprint verification dialog, like the one in the following image:

      Confirming your SSH Fingerprint

      This is to ensure that you are really connecting to the server you think you are. You can verify this by logging in to your server manually and running ssh-keygen -l -f /etc/ssh/ssh_host_key.pub to view the fingerprint of the server. If this fingerprint is the same as the one being presented to you in Visual Studio Code, then you are indeed connecting to the server you think you are so you can click Continue.

      Visual Studio Code defaults to opening a new window when a new connection is made. A new window will appear with the welcome screen. You’ll know that your connection was successful if you see SSH: your_ip_address_or_hostname in the green box in the bottom left-hand corner. This means that Visual Studio Code is connected and communicating with your remote server.

      Successful SSH connection

      Now that you’re connected, you can run commands and code from your editor.

      Step 3 — Executing Code on the Remote Server

      The Remote-SSH plugin is configured, and it’s time to run some code on your remote machine. Open a terminal window by selecting Terminal from the navigation bar at the top of the Visual Studio window and clicking New Terminal. You can also open a terminal by pressing CTRL+Shift+`. The terminal that is opened is a terminal on your remote server, not one on your local machine.

      When the terminal opens, issue the following command to view the IP address of your server to verify that you are connected to your remote server:

      You’ll see the following output in your terminal:

      Output

      1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 16:cb:05:5b:30:f1 brd ff:ff:ff:ff:ff:ff inet your_server_ip brd your_broadcast_address scope global eth0 valid_lft forever preferred_lft forever ...

      To test out the ability to run remote code, create a new Python file called hello.py in your editor. When you are connected to your remote server, all files created through Visual Studio Code will be saved to that server, not on your local machine.

      Add the following contents to the file:

      hello.py

      print("Hello Sammy!")
      

      To run this program on your server, open a terminal in Visual Studio Code from the navigation menu or by pressing the key sequence CTRL+Shift+`. Since this terminal session is connected to your remote server, run the following command in the terminal to execute your hello.py program:

      Your program’s output will be displayed.

      Executing your Python Script

      You can also execute the file from the Debug context menu by selecting Run without Debugging.

      Note: If you have any development extensions installed in Visual Studio Code, like the Python extension, you will have to reinstall these extensions on your server through the Extension Marketplace. If you have previously installed these plugins in Visual Studio Code, when you search for them again, the Marketplace will say Install on SSH: hostname. Always pay attention to what devlopment context you are in, because this is where Visual Studio Code will install your plugins and create your files. If you try to run your code without these plugins installed, error dialog boxes will appear in the bottom right-hand corner of the screen prompting you to install them on your remote server. After you have installed these they will likely require you to reload Visual Studio Code. When you relaunch it, it will continue working on the remote server without you having to manually reconnect.

      Conclusion

      You now have Visual Studio Code configured for development on a remote server using SSH. Remote execution with an IDE provides many benefits, including the ability to quickly test how your code runs on different operating systems and different hardware specifications. As long as you have an internet connection you could connect to your server and work on your code from any computer, and you’ll be able to develop using a Linux environment even if you run Windows as your primary operating system.



      Source link

      How To Use nsh to Run Secure Remote Commands On Ubuntu 18.04


      Introduction

      It can often be difficult to manage multiple machines on a daily basis. While Secure Shell (SSH) is a good choice for remote access, the protocol itself has some drawbacks in both convenience and security.

      For instance, remote machines need to have a public IP address and a forwarded port in order to access them, which exposes them to the internet, or at least a larger network. This is especially concerning if you use a password for authentication instead of a public and private key pair. Furthermore, if you don’t know the remote machine’s public key in advance, you might be vulnerable to a “man-in-the-middle” attack. And many remote machines you want to access either don’t have public IP address, or they have a dynamic IP address you might not know.

      In addition, SSH requires one connection per remote session. If a user needs to run a single command across hundreds or even thousands of machines, they must first establish a connection to each machine with a TCP handshake, which is less efficient.

      NKN Shell, or nsh, is an alternative to SSH that provides a convenient and secure way to run remote commands. nsh takes advantage of NKN’s global public network which provides secure and decentralized data transmission. The architecture uses unique addresses that contain a public key used for both routing and end-to-end encryption without any public key infrastructure (PKI). The network also does not require the remote server to have a public IP address. The remote server only needs to have Internet access and be able to establish outbound HTTP and websocket connections. As a result, your remote machines are not exposed to the open Internet.

      In this tutorial you will use the NKN shell daemon and the NKN Shell Client Xterm applications to execute commands on a remote machine. To do so, you will install and configure the NKN Shell daemon on a remote machine with internet access, generate a key pair, and make your connection from a client.

      Prerequisites

      To follow this tutorial you will need the following:

      Step 1 — Installing NKN Shell Daemon on a Remote Server

      First, install the NKN shell daemon (nsd) on your server. This application will invoke nkn-multiclient, which will connect to NKN’s public network and obtain an address for routing. The daemon will then listen for incoming shell commands from authenticated and whitelisted clients, execute those commands, and then send back results.

      Start by downloading the latest pre-built nshd binary from GitHub:

      • wget https://github.com/nknorg/nkn-shell-daemon/releases/latest/download/linux-amd64.tar.gz

      Decompress the file:

      • tar -zxvf linux-amd64.tar.gz

      Then move the files into the /usr/local/bin directory so they are available system wide:

      • sudo mv ./linux-amd64/* /usr/local/bin/

      Next, you’ll configure this to run as a daemon process using Systemd so that it will restart if the server is reset.

      Create a file called nshd.service in /etc/systemd/system:

      • sudo nano /etc/systemd/system/nshd.service

      Add the following service definition to the file to configure the service:

      /etc/systemd/system/nshd.service

      [Unit]
      Description=NKN Shell Daemon
      After=network.target
      
      [Service]
      Type=simple
      User=root
      Group=root
      Restart=always
      ExecStart=/usr/local/bin/nshd
      
      [Install]
      WantedBy=multi-user.target
      

      Learn more about Systemd unit files in Understanding Systemd Units and Unit Files.

      Save the file and exit the editor. Then enable and start the nshd service with the following commands:

      • sudo systemctl enable nshd.service
      • sudo systemctl start nshd.service

      Run the following command to ensure the service is active and started:

      • sudo systemctl status nshd.service

      You’ll see that the status is active:

      Output

      ● nshd.service - NKN Shell Daemon Loaded: loaded (/etc/systemd/system/nshd.service; enabled; vendor preset: enabled) Active: active (running) since Wed 2020-02-19 19:16:02 UTC; 7s ago Main PID: 3457 (nshd) Tasks: 10 (limit: 1152) CGroup: /system.slice/nshd.service └─3457 /usr/local/bin/nshd Feb 19 19:16:02 your_hostname systemd[1]: Started NKN Shell Daemon. Feb 19 19:16:03 your_hostname nshd[3457]: Create directory /etc/nshd/ Feb 19 19:16:03 your_hostname nshd[3457]: Create password and save to file /etc/nshd/wallet.pswd Feb 19 19:16:03 your_hostname nshd[3457]: Create wallet and save to file /etc/nshd/wallet.json Feb 19 19:16:03 your_hostname nshd[3457]: Create authorized pubkeys file /etc/nshd/authorized_pubkeys Feb 19 19:16:03 your_hostname nshd[3457]: Listening at d46567b883a3070ee3fe879d9fa2d5dc55a95f79ff2797c42df36c6979e5c4Aba

      In order to connect to your server, you’ll need to get its NKN address, which you can find in the output of the previous command. You can also run the following command to obtain the address:

      You’ll see your address appear:

      Output

      e70ca28ede84fc0659f2869255e8a393aef35b4fa5a7e036f29127c7dba75383

      Take note of this address as you will need it to connect to your server.

      Now that the daemon is running and listening, you can configure the web-based client to talk to the server.

      Step 2 — Configuring Permissions for NKN Shell Client

      You’ll need a compatible client that can connect to the remote machine. In this tutorial you’ll use NKN Shell Client Xterm, a web-based NKN shell client. There are a few different ways to run it:

      In this tutorial you’ll use the hosted version. On your local machine, open your web browser and navigate to https://nsh.nkn.org. You’ll see a welcome screen:

      The Shell Client

      Click Generate New Key Pair. Your keys will be generated and displayed as shown in the following image:

      The generated key pair

      Note: When you generate a new key pair, you will see a Secret Seed. Keep this secret seed secure and safe, just like you would with your SSH private key. Anyone who has this secret seed can use it to regenerate your public key and then run commands on your remote machines. Your browser will remember this seed, but you should copy it somewhere safe so you can use it again on a new machine.

      Save the Secret Seed somewhere safe. You can use it later to regenerate your public key so you can connect from a different client machine.

      Since this is a new key pair, you must add the Public Key to the file /etc/nshd/authorized_pubkeys on your server.

      /etc/nshd/authorized_pubkeys has a similar role as the ~/authorized_keys file which controls which SSH public keys can log in. The authorized_pubkeys file can specify which user is associated with a key. For security purposes, you’ll want to log in using a non-root user in this tutorial, so you’ll associate the generated public key with your sammy user you created in the Initial Server Setup guide in this article’s prerequisite.

      To associate a user with the public key, you’ll need to get the user id (UID) and group id (GID) of this user. Execute the following command on your server while logged in as the sammy user:

      You’ll see the UID and GID of the user:

      Output

      uid=1000(sammy) gid=1000(sammy) groups=1000(sammy),27(sudo)

      Now open the authorized_pubkeys file in your editor:

      • sudo nano /etc/nshd/authorized_pubkeys

      Add a single line containing the public key, uid, and gid, separated by spaces:

      authorized_pubkeys

      5d5367a5730427c205904a4457392051d2045dbce0186518fb6eb24dd9e41ba6 1000 1000
      

      Save the file.

      Verify that the file contains the correct content:

      • cat /etc/nshd/authorized_pubkeys

      You’ll see your key printed on the screen:

      Output

      5d5367a5730427c205904a4457392051d2045dbce0186518fb6eb24dd9e41ba6 1000 1000

      Then restart the nshd daemon to apply the changes:

      • sudo systemctl restart nshd.service

      Now let’s test it out by connecting to the server and running a command.

      Step 3 — Sending a Command to the remote machine and receive a response

      In NKN Shell Client, enter your remote nshd address from Step 1, as well as an optional client identifier:

      The nsh website with remote address filled in

      Click Connect to initiate the connection.

      You’ll be connected to your remote machine and shown a terminal prompt within the browser. From here you can use it just like SSH. For example, execute the following command to switch to the /etc/nshd directory:

      Then list its contents:

      You’ll see the contents of the directory:

      Output

      authorized_pubkeys wallet.json wallet.pswd

      You can disconnect by typing exit. When you need to reconnect, revisit the web interface and enter your connection details. If you generate a new key pair, you’ll need to add the new public key to your server.

      Conclusion

      In this tutorial, you installed and configured nsh to securely and conveniently send commands to a remote machine. nsh is a great way to access your remote machines when you need to quickly run a command to get the latest status of a service or peek at some configuration settings. The application is based on NKN’s global public network, and it’s free to use so you can incorporate it into your own application or workflow today.

      You can also explore nkn-tunnel which supports SSH or any other TCP based applications.



      Source link