One place for hosting & domains

      Debian

      How to Set Up SSH Keys on Debian 9


      Introduction

      SSH, or secure shell, is an encrypted protocol used to administer and communicate with servers. When working with a Debian server, chances are you will spend most of your time in a terminal session connected to your server through SSH.

      In this guide, we’ll focus on setting up SSH keys for a vanilla Debian 9 installation. SSH keys provide an easy, secure way of logging into your server and are recommended for all users.

      Step 1 — Create the RSA Key Pair

      The first step is to create a key pair on the client machine (usually your computer):

      By default ssh-keygen will create a 2048-bit RSA key pair, which is secure enough for most use cases (you may optionally pass in the -b 4096 flag to create a larger 4096-bit key).

      After entering the command, you should see the following output:

      Output

      Generating public/private rsa key pair. Enter file in which to save the key (/your_home/.ssh/id_rsa):

      Press enter to save the key pair into the .ssh/ subdirectory in your home directory, or specify an alternate path.

      If you had previously generated an SSH key pair, you may see the following prompt:

      Output

      /home/your_home/.ssh/id_rsa already exists. Overwrite (y/n)?

      If you choose to overwrite the key on disk, you will not be able to authenticate using the previous key anymore. Be very careful when selecting yes, as this is a destructive process that cannot be reversed.

      You should then see the following prompt:

      Output

      Enter passphrase (empty for no passphrase):

      Here you optionally may enter a secure passphrase, which is highly recommended. A passphrase adds an additional layer of security to prevent unauthorized users from logging in. To learn more about security, consult our tutorial on How To Configure SSH Key-Based Authentication on a Linux Server.

      You should then see the following output:

      Output

      Your identification has been saved in /your_home/.ssh/id_rsa. Your public key has been saved in /your_home/.ssh/id_rsa.pub. The key fingerprint is: a9:49:2e:2a:5e:33:3e:a9:de:4e:77:11:58:b6:90:26 username@remote_host The key's randomart image is: +--[ RSA 2048]----+ | ..o | | E o= . | | o. o | | .. | | ..S | | o o. | | =o.+. | |. =++.. | |o=++. | +-----------------+

      You now have a public and private key that you can use to authenticate. The next step is to place the public key on your server so that you can use SSH-key-based authentication to log in.

      Step 2 — Copy the Public Key to Debian Server

      The quickest way to copy your public key to the Debian host is to use a utility called ssh-copy-id. Due to its simplicity, this method is highly recommended if available. If you do not have ssh-copy-id available to you on your client machine, you may use one of the two alternate methods provided in this section (copying via password-based SSH, or manually copying the key).

      Copying Public Key Using ssh-copy-id

      The ssh-copy-id tool is included by default in many operating systems, so you may have it available on your local system. For this method to work, you must already have password-based SSH access to your server.

      To use the utility, you simply need to specify the remote host that you would like to connect to and the user account that you have password SSH access to. This is the account to which your public SSH key will be copied.

      The syntax is:

      • ssh-copy-id username@remote_host

      You may see the following message:

      Output

      The authenticity of host '203.0.113.1 (203.0.113.1)' can't be established. ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe. Are you sure you want to continue connecting (yes/no)? yes

      This means that your local computer does not recognize the remote host. This will happen the first time you connect to a new host. Type "yes" and press ENTER to continue.

      Next, the utility will scan your local account for the id_rsa.pub key that we created earlier. When it finds the key, it will prompt you for the password of the remote user's account:

      Output

      /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys username@203.0.113.1's password:

      Type in the password (your typing will not be displayed for security purposes) and press ENTER. The utility will connect to the account on the remote host using the password you provided. It will then copy the contents of your ~/.ssh/id_rsa.pub key into a file in the remote account's home ~/.ssh directory called authorized_keys.

      You should see the following output:

      Output

      Number of key(s) added: 1 Now try logging into the machine, with: "ssh 'username@203.0.113.1'" and check to make sure that only the key(s) you wanted were added.

      At this point, your id_rsa.pub key has been uploaded to the remote account. You can continue on to Step 3.

      Copying Public Key Using SSH

      If you do not have ssh-copy-id available, but you have password-based SSH access to an account on your server, you can upload your keys using a conventional SSH method.

      We can do this by using the cat command to read the contents of the public SSH key on our local computer and piping that through an SSH connection to the remote server.

      On the other side, we can make sure that the ~/.ssh directory exists and has the correct permissions under the account we’re using.

      We can then output the content we piped over into a file called authorized_keys within this directory. We’ll use the >> redirect symbol to append the content instead of overwriting it. This will let us add keys without destroying previously added keys.

      The full command looks like this:

      • cat ~/.ssh/id_rsa.pub | ssh username@remote_host "mkdir -p ~/.ssh && touch ~/.ssh/authorized_keys && chmod -R go= ~/.ssh && cat >> ~/.ssh/authorized_keys"

      You may see the following message:

      Output

      The authenticity of host '203.0.113.1 (203.0.113.1)' can't be established. ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe. Are you sure you want to continue connecting (yes/no)? yes

      This means that your local computer does not recognize the remote host. This will happen the first time you connect to a new host. Type "yes" and press ENTER to continue.

      Afterwards, you should be prompted to enter the remote user account password:

      Output

      username@203.0.113.1's password:

      After entering your password, the content of your id_rsa.pub key will be copied to the end of the authorized_keys file of the remote user's account. Continue on to Step 3 if this was successful.

      Copying Public Key Manually

      If you do not have password-based SSH access to your server available, you will have to complete the above process manually.

      We will manually append the content of your id_rsa.pub file to the ~/.ssh/authorized_keys file on your remote machine.

      To display the content of your id_rsa.pub key, type this into your local computer:

      You will see the key's content, which should look something like this:

      Output

      ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCqql6MzstZYh1TmWWv11q5O3pISj2ZFl9HgH1JLknLLx44+tXfJ7mIrKNxOOwxIxvcBF8PXSYvobFYEZjGIVCEAjrUzLiIxbyCoxVyle7Q+bqgZ8SeeM8wzytsY+dVGcBxF6N4JS+zVk5eMcV385gG3Y6ON3EG112n6d+SMXY0OEBIcO6x+PnUSGHrSgpBgX7Ks1r7xqFa7heJLLt2wWwkARptX7udSq05paBhcpB0pHtA1Rfz3K2B+ZVIpSDfki9UVKzT8JUmwW6NNzSgxUfQHGwnW7kj4jp4AT0VZk3ADw497M2G/12N0PPB5CnhHf7ovgy6nL1ikrygTKRFmNZISvAcywB9GVqNAVE+ZHDSCuURNsAInVzgYo9xgJDW8wUw2o8U77+xiFxgI5QSZX3Iq7YLMgeksaO4rBJEa54k8m5wEiEE1nUhLuJ0X/vh2xPff6SQ1BL/zkOhvJCACK6Vb15mDOeCSq54Cr7kvS46itMosi/uS66+PujOO+xt/2FWYepz6ZlN70bRly57Q06J+ZJoc9FfBCbCyYH7U/ASsmY095ywPsBo1XQ9PqhnN1/YOorJ068foQDNVpm146mUpILVxmq41Cj55YKHEazXGsdBIbXWhcrRf4G2fJLRcGUr9q8/lERo9oxRm5JFX6TCmj6kmiFqv+Ow9gI0x8GvaQ== demo@test

      Access your remote host using whichever method you have available.

      Once you have access to your account on the remote server, you should make sure the ~/.ssh directory exists. This command will create the directory if necessary, or do nothing if it already exists:

      Now, you can create or modify the authorized_keys file within this directory. You can add the contents of your id_rsa.pub file to the end of the authorized_keys file, creating it if necessary, using this command:

      • echo public_key_string >> ~/.ssh/authorized_keys

      In the above command, substitute the public_key_string with the output from the cat ~/.ssh/id_rsa.pub command that you executed on your local system. It should start with ssh-rsa AAAA....

      Finally, we’ll ensure that the ~/.ssh directory and authorized_keys file have the appropriate permissions set:

      This recursively removes all “group” and “other” permissions for the ~/.ssh/ directory.

      If you’re using the root account to set up keys for a user account, it’s also important that the ~/.ssh directory belongs to the user and not to root:

      • chown -R sammy:sammy ~/.ssh

      In this tutorial our user is named sammy but you should substitute the appropriate username into the above command.

      We can now attempt passwordless authentication with our Debian server.

      Step 3 — Authenticate to Debian Server Using SSH Keys

      If you have successfully completed one of the procedures above, you should be able to log into the remote host without the remote account's password.

      The basic process is the same:

      If this is your first time connecting to this host (if you used the last method above), you may see something like this:

      Output

      The authenticity of host '203.0.113.1 (203.0.113.1)' can't be established. ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe. Are you sure you want to continue connecting (yes/no)? yes

      This means that your local computer does not recognize the remote host. Type "yes" and then press ENTER to continue.

      If you did not supply a passphrase for your private key, you will be logged in immediately. If you supplied a passphrase for the private key when you created the key, you will be prompted to enter it now (note that your keystrokes will not display in the terminal session for security). After authenticating, a new shell session should open for you with the configured account on the Debian server.

      If key-based authentication was successful, continue on to learn how to further secure your system by disabling password authentication.

      Step 4 — Disable Password Authentication on your Server

      If you were able to log into your account using SSH without a password, you have successfully configured SSH-key-based authentication to your account. However, your password-based authentication mechanism is still active, meaning that your server is still exposed to brute-force attacks.

      Before completing the steps in this section, make sure that you either have SSH-key-based authentication configured for the root account on this server, or preferably, that you have SSH-key-based authentication configured for a non-root account on this server with sudo privileges. This step will lock down password-based logins, so ensuring that you will still be able to get administrative access is crucial.

      Once you've confirmed that your remote account has administrative privileges, log into your remote server with SSH keys, either as root or with an account with sudo privileges. Then, open up the SSH daemon's configuration file:

      • sudo nano /etc/ssh/sshd_config

      Inside the file, search for a directive called PasswordAuthentication. This may be commented out. Uncomment the line and set the value to "no". This will disable your ability to log in via SSH using account passwords:

      /etc/ssh/sshd_config

      ...
      PasswordAuthentication no
      ...
      

      Save and close the file when you are finished by pressing CTRL + X, then Y to confirm saving the file, and finally ENTER to exit nano. To actually implement these changes, we need to restart the sshd service:

      • sudo systemctl restart ssh

      As a precaution, open up a new terminal window and test that the SSH service is functioning correctly before closing this session:

      Once you have verified your SSH service, you can safely close all current server sessions.

      The SSH daemon on your Debian server now only responds to SSH keys. Password-based authentication has successfully been disabled.

      Conclusion

      You should now have SSH-key-based authentication configured on your server, allowing you to sign in without providing an account password.

      If you'd like to learn more about working with SSH, take a look at our SSH Essentials Guide.



      Source link

      Initial Server Setup with Debian 9


      Introduction

      When you first create a new Debian 9 server, there are a few configuration steps that you should take early on as part of the basic setup. This will increase the security and usability of your server and will give you a solid foundation for subsequent actions.

      Step One — Logging in as Root

      To log into your server, you will need to know your server’s public IP address. You will also need the password or, if you installed an SSH key for authentication, the private key for the root user’s account. If you have not already logged into your server, you may want to follow our guide on how to connect to your Droplet with SSH, which covers this process in detail.

      If you are not already connected to your server, go ahead and log in as the root user using the following command (substitute the highlighted portion of the command with your server’s public IP address):

      Accept the warning about host authenticity if it appears. If you are using password authentication, provide your root password to log in. If you are using an SSH key that is passphrase protected, you may be prompted to enter the passphrase the first time you use the key each session. If this is your first time logging into the server with a password, you may also be prompted to change the root password.

      About Root

      The root user is the administrative user in a Linux environment that has very broad privileges. Because of the heightened privileges of the root account, you are discouraged from using it on a regular basis. This is because part of the power inherent with the root account is the ability to make very destructive changes, even by accident.

      The next step is to set up an alternative user account with a reduced scope of influence for day-to-day work. We'll teach you how to gain increased privileges during the times when you need them.

      Step Two — Creating a New User

      Once you are logged in as root, we're prepared to add the new user account that we will use to log in from now on.

      Note: In some environments, a package called unscd may be installed by default in order to speed up requests to name servers like LDAP. The most recent version currently available in Debian contains a bug that causes certain commands (like the adduser command below) to produce additional output that looks like this:

      sent invalidate(passwd) request, exiting
      sent invalidate(group) request, exiting
      

      These messages are harmless, but if you wish to avoid them, it is safe to remove the unscd package if you do not not plan on using systems like LDAP for user information:

      This example creates a new user called sammy, but you should replace it with a username that you like:

      You will be asked a few questions, starting with the account password.

      Enter a strong password and, optionally, fill in any of the additional information if you would like. This is not required and you can just hit ENTER in any field you wish to skip.

      Step Three — Granting Administrative Privileges

      Now, we have a new user account with regular account privileges. However, we may sometimes need to do administrative tasks.

      To avoid having to log out of our normal user and log back in as the root account, we can set up what is known as "superuser" or root privileges for our normal account. This will allow our normal user to run commands with administrative privileges by putting the word sudo before each command.

      To add these privileges to our new user, we need to add the new user to the sudo group. By default, on Debian 9, users who belong to the sudo group are allowed to use the sudo command.

      As root, run this command to add your new user to the sudo group (substitute the highlighted word with your new user):

      Now, when logged in as your regular user, you can type sudo before commands to perform actions with superuser privileges.

      Step Four — Setting Up a Basic Firewall

      Debian servers can use firewalls to make sure only connections to certain services are allowed. Although the iptables firewall is installed by default, Debian does not strongly recommend any specific firewall. In this guide, we will install and use the UFW firewall to help set policies and manage exceptions.

      We can use the apt package manager to install UFW. Update the local index to retrieve the latest information about available packages and then install the firewall by typing:

      • apt update
      • apt install ufw

      Note: If your servers are running on DigitalOcean, you can optionally use DigitalOcean Cloud Firewalls instead of the UFW firewall. We recommend using only one firewall at a time to avoid conflicting rules that may be difficult to debug.

      Firewall profiles allow UFW to manage sets of firewall rules for applications by name. Profiles for some common software are bundled with UFW by default and packages can register additional profiles with UFW during the installation process. OpenSSH, the service allowing us to connect to our server now, has a firewall profile that we can use.

      You can see this by typing:

      Output

      Available applications: . . . OpenSSH . . .

      We need to make sure that the firewall allows SSH connections so that we can log back in next time. We can allow these connections by typing:

      Afterwards, we can enable the firewall by typing:

      Type "y" and press ENTER to proceed. You can see that SSH connections are still allowed by typing:

      Output

      Status: active To Action From -- ------ ---- OpenSSH ALLOW Anywhere OpenSSH (v6) ALLOW Anywhere (v6)

      As the firewall is currently blocking all connections except for SSH, if you install and configure additional services, you will need to adjust the firewall settings to allow acceptable traffic in. You can learn some common UFW operations in this guide.

      Step Five — Enabling External Access for Your Regular User

      Now that we have a regular user for daily use, we need to make sure we can SSH into the account directly.

      Note: Until verifying that you can log in and use sudo with your new user, we recommend staying logged in as root. This way, if you have problems, you can troubleshoot and make any necessary changes as root. If you are using a DigitalOcean Droplet and experience problems with your root SSH connection, you can log into the Droplet using the DigitalOcean Console.

      The process for configuring SSH access for your new user depends on whether your server's root account uses a password or SSH keys for authentication.

      If the Root Account Uses Password Authentication

      If you logged in to your root account using a password, then password authentication is enabled for SSH. You can SSH to your new user account by opening up a new terminal session and using SSH with your new username:

      After entering your regular user's password, you will be logged in. Remember, if you need to run a command with administrative privileges, type sudo before it like this:

      You will be prompted for your regular user password when using sudo for the first time each session (and periodically afterwards).

      To enhance your server's security, we strongly recommend setting up SSH keys instead of using password authentication. Follow our guide on setting up SSH keys on Debian 9 to learn how to configure key-based authentication.

      If the Root Account Uses SSH Key Authentication

      If you logged in to your root account using SSH keys, then password authentication is disabled for SSH. You will need to add a copy of your local public key to the new user's ~/.ssh/authorized_keys file to log in successfully.

      Since your public key is already in the root account's ~/.ssh/authorized_keys file on the server, we can copy that file and directory structure to our new user account in our existing session with the cp command. Afterwards, we can adjust ownership of the files using the chown command.

      Make sure to change the highlighted portions of the command below to match your regular user's name:

      • cp -r ~/.ssh /home/sammy
      • chown -R sammy:sammy /home/sammy/.ssh

      Now, open up a new terminal session and using SSH with your new username:

      You should be logged in to the new user account without using a password. Remember, if you need to run a command with administrative privileges, type sudo before it like this:

      You will be prompted for your regular user password when using sudo for the first time each session (and periodically afterwards).

      Step Six — Completing Optional Configuration

      Now that we have a strong baseline configuration, we can consider a few optional steps to make the system more accessible. The following sections cover a few additional tweaks focused on usability.

      Installing man Pages

      Debian provides extensive manuals for most software in the form of man pages. However, the man command is not always included by default on minimal installations.

      Install the man-db package to install the man command and the manual databases:

      Now, to view the manual for a component, you can type:

      For example, to view the manual for the top command, type:

      Most packages in the Debian repositories include manual pages as part of their installation.

      Changing the Default Editor

      Debian offers a wide variety of text editors, some of which are included in the base system. Commands with integrated editor support, like visudo and systemctl edit, pass text to the editor command, which is mapped to the system default editor. Setting the default editor according to your preferences can help you configure your system more easily and avoid frustration.

      If your preferred editor is not installed by default, use apt to install it first:

      • sudo apt install your_preferred_editor

      Next, you can view the current default and modify the selection using the update-alternatives command:

      • sudo update-alternatives --config editor

      The command displays a table of the editors it knows about with a prompt to change the default:

      Output

      There are 8 choices for the alternative editor (providing /usr/bin/editor). Selection Path Priority Status ------------------------------------------------------------ * 0 /usr/bin/joe 70 auto mode 1 /bin/nano 40 manual mode 2 /usr/bin/jmacs 50 manual mode 3 /usr/bin/joe 70 manual mode 4 /usr/bin/jpico 50 manual mode 5 /usr/bin/jstar 50 manual mode 6 /usr/bin/rjoe 25 manual mode 7 /usr/bin/vim.basic 30 manual mode 8 /usr/bin/vim.tiny 15 manual mode Press <enter> to keep the current choice[*], or type selection number:

      The asterisk in the far left column indicates the current selection. To change the default, type the "Selection" number for your preferred editor and press Enter. For example, to use nano as the default editor given the above table, we would choose 1:

      Output

      Press <enter> to keep the current choice[*], or type selection number: 1 update-alternatives: using /bin/nano to provide /usr/bin/editor (editor) in manual mode

      From now on, your preferred editor will be used by commands like visudo and systemctl edit, or when the editor command is called.

      Where To Go From Here?

      At this point, you have a solid foundation for your server. You can install any of the software you need on your server now.



      Source link

      How To Install Node.js on Debian 9


      Introduction

      Node.js is a JavaScript platform for general-purpose programming that allows users to build network applications quickly. By leveraging JavaScript on both the front and backend, Node.js makes development more consistent and integrated.

      In this guide, we’ll show you how to get started with Node.js on a Debian 9 server.

      Prerequisites

      This guide assumes that you are using Debian 9. Before you begin, you should have a non-root user account with sudo privileges set up on your system. You can learn how to set this up by following the initial server setup for Debian 9.

      Installing the Distro-Stable Version for Debian

      Debian contains a version of Node.js in its default repositories. At the time of writing, this version is 4.8.2, which will reach end-of-life at the end of April 2018. If you would like to experiment with the language using a stable and sufficient option, then installing from the repositories may make sense. It is recommended, however, that for development and production use cases you install a more recent version with a PPA. We will discuss how to install from a PPA in the next step.

      To get the distro-stable version of Node.js, you can use the apt package manager. First, refresh your local package index:

      Then install the Node.js package from the repositories:

      If the package in the repositories suits your needs, then this is all you need to do to get set up with Node.js.

      To check which version of Node.js you have installed after these initial steps, type:

      Because of a conflict with another package, the executable from the Debian repositories is called nodejs instead of node. Keep this in mind as you are running software.

      Once you have established which version of Node.js you have installed from the Debian repositories, you can decide whether or not you would like to work with different versions, package archives, or version managers. Next, we'll discuss these elements, along with more flexible and robust methods of installation.

      Installing Using a PPA

      To work with a more recent version of Node.js, you can add the PPA (personal package archive) maintained by NodeSource. This will have more up-to-date versions of Node.js than the official Debian repositories, and will allow you to choose between Node.js v4.x (the older long-term support version, which will be supported until the end of April 2018), Node.js v6.x (supported until April of 2019), Node.js v8.x (the current LTS version, supported until December of 2019), and Node.js v10.x (the latest version, supported until April of 2021).

      Let's first update the local package index and install curl, which you will use to access the PPA:

      • sudo apt update
      • sudo apt install curl

      Next, let's install the PPA in order to get access to its contents. From your home directory, use curl to retrieve the installation script for your preferred version, making sure to replace 10.x with your preferred version string (if different):

      • cd ~
      • curl -sL https://deb.nodesource.com/setup_10.x -o nodesource_setup.sh

      You can inspect the contents of this script with nano or your preferred text editor:

      Run the script under sudo:

      • sudo bash nodesource_setup.sh

      The PPA will be added to your configuration and your local package cache will be updated automatically. After running the setup script, you can install the Node.js package in the same way you did above:

      To check which version of Node.js you have installed after these initial steps, type:

      Output

      v10.9.0

      The nodejs package contains the nodejs binary as well as npm, so you don't need to install npm separately.

      npm uses a configuration file in your home directory to keep track of updates. It will be created the first time you run npm. Execute this command to verify that npm is installed and to create the configuration file:

      Output

      6.2.0

      In order for some npm packages to work (those that require compiling code from source, for example), you will need to install the build-essential package:

      • sudo apt install build-essential

      You now have the necessary tools to work with npm packages that require compiling code from source.

      Installing Using NVM

      An alternative to installing Node.js through apt is to use a tool called nvm, which stands for "Node.js Version Manager". Rather than working at the operating system level, nvm works at the level of an independent directory within your home directory. This means that you can install multiple self-contained versions of Node.js without affecting the entire system.

      Controlling your environment with nvm allows you to access the newest versions of Node.js and retain and manage previous releases. It is a different utility from apt, however, and the versions of Node.js that you manage with it are distinct from those you manage with apt.

      To download the nvm installation script from the project's GitHub page, you can use curl. Note that the version number may differ from what is highlighted here:

      • curl -sL https://raw.githubusercontent.com/creationix/nvm/v0.33.11/install.sh -o install_nvm.sh

      Inspect the installation script with nano:

      Run the script with bash:

      It will install the software into a subdirectory of your home directory at ~/.nvm. It will also add the necessary lines to your ~/.profile file to use the file.

      To gain access to the nvm functionality, you'll need to either log out and log back in again or source the ~/.profile file so that your current session knows about the changes:

      With nvm installed, you can install isolated Node.js versions. For information about the versions of Node.js that are available, type:

      Output

      ... v8.11.1 (Latest LTS: Carbon) v9.0.0 v9.1.0 v9.2.0 v9.2.1 v9.3.0 v9.4.0 v9.5.0 v9.6.0 v9.6.1 v9.7.0 v9.7.1 v9.8.0 v9.9.0 v9.10.0 v9.10.1 v9.11.0 v9.11.1 v10.0.0 v10.1.0 v10.2.0 v10.2.1 v10.3.0 v10.4.0 v10.4.1 v10.5.0 v10.6.0 v10.7.0 v10.8.0 v10.9.0

      As you can see, the current LTS version at the time of this writing is v8.11.1. You can install that by typing:

      Usually, nvm will switch to use the most recently installed version. You can tell nvm to use the version you just downloaded by typing:

      When you install Node.js using nvm, the executable is called node. You can see the version currently being used by the shell by typing:

      Output

      v8.11.1

      If you have multiple Node.js versions, you can see what is installed by typing:

      If you wish to default one of the versions, type:

      This version will be automatically selected when a new session spawns. You can also reference it by the alias like this:

      Each version of Node.js will keep track of its own packages and has npm available to manage these.

      You can also have npm install packages to the Node.js project's ./node_modules directory. Use the following syntax to install the express module:

      If you'd like to install the module globally, making it available to other projects using the same version of Node.js, you can add the -g flag:

      This will install the package in:

      ~/.nvm/versions/node/node_version/lib/node_modules/express
      

      Installing the module globally will let you run commands from the command line, but you'll have to link the package into your local sphere to require it from within a program:

      You can learn more about the options available to you with nvm by typing:

      Removing Node.js

      You can uninstall Node.js using apt or nvm, depending on the version you want to target. To remove versions installed from the repositories or from the PPA, you will need to work with the apt utility at the system level.

      To remove either of these versions, type the following:

      This command will remove the package and the configuration files.

      To uninstall a version of Node.js that you have enabled using nvm, first determine whether or not the version you would like to remove is the current active version:

      If the version you are targeting is not the current active version, you can run:

      • nvm uninstall node_version

      This command will uninstall the selected version of Node.js.

      If the version you would like to remove is the current active version, you must first deactivate nvm to enable your changes:

      You can now uninstall the current version using the uninstall command above, which will remove all files associated with the targeted version of Node.js except the cached files that can be used for reinstallation.

      Conclusion

      There are a quite a few ways to get up and running with Node.js on your Debian 9 server. Your circumstances will dictate which of the above methods is best for your needs. While using the packaged version in the Debian repository is an option for experimentation, installing from a PPA and working with npm or nvm offers additional flexibility.



      Source link