Allow an outside client to access my Linode without seeing account or billing information

Linode Staff

I would like an outside client/developer to have access to one of my Linodes, but I don't want them to have access to any other Linodes or see my billing information. Is this possible? If so, how can I make this happen?

1 Reply

This is absolutely possible on our platform. There are two separate forms of access that you can allow your outside party to have:

  • Firstly, you can establish administrative access to that Linode's internal environment.
  • Secondly, you can establish access to that Linode through Cloud Manager.

For most tasks, an outside party will need administrative internal access to a Linode, so I will cover this first. This also has the advantage of them not needing any access permissions to your Linode account itself through Cloud Manager.

Before I do so, I would like to take a moment to cover how to identify the correct Linode that an administrator needs to access.

Which Linode will you use?

Before doing anything else, it is important to identify which Linode your outside party will need to access. This will be crucial to make sure that they are performing their work on the correct Linode.

Identify Linode by IP address

Your outside party may provide you a domain or an IP address. If they give you an IP address, it should be easy to identify the correct Linode by matching its IP address in the list of all of your Linodes:

If you don't see the IP address in this list, you may need to navigate to the next page using the page selector at the very bottom of this page. You can also configure Cloud Manager to display more Linodes per page.

If you still don't see a match at this point, you may want to make sure that they are providing you the correct IP address and that your service is hosted at Linode. However, there are some other possibilities to consider, such as the use of a NodeBalancer or an external Cloudflare service. These possibilities are covered further below.

Potential for using a NodeBalancer

If you're not seeing the IP address for your Linode, there's a chance that this Linode is behind a NodeBalancer. To identify this possibility, try to match the IP address to a NodeBalancer from this page:

If you see a matching IP address for this NodeBalancer, click that NodeBalancer's label, select its Configuration tab, and expand the relevant configuration (port 80 or 443 for a website).

From this page, scroll down to the "Backend Nodes" section. This will show you your backend nodes. To match the backend nodes to the Linodes on your account that your outside party must access, you will need to click the "IP Address" to reveal the labels of these Linodes. You will then need to match these labels to to a Linodes from your list of Linodes here:

We are currently exploring how to streamline this matching process.

Identify Linode by domain

If they provide you a domain, you will need to see which Linode that domain corresponds to. To do this, you will need to perform a domain lookup from a command prompt. Here are some instructions for opening up a command prompt on common platforms:

Once in the command prompt, you can run the command nslookup to perform this lookup, replacing with the actual domain you are using:

$ nslookup

Non-authoritative answer:

You will need to press the Enter or Return key after typing nslookup to run this command and see these results.

If your system doesn't have nslookup, you may want to try dig instead:

$ dig

; <<>> DiG 9.10.6 <<>>
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45548
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

; EDNS: version: 0, flags:; udp: 4096
;                   IN      A

;; ANSWER SECTION:            2673    IN      A

;; Query time: 45 msec
;; WHEN: Thu Jan 28 14:50:30 EST 2021
;; MSG SIZE  rcvd: 56

You will then need to match up the IP address(es) outputted in the Address lines (if using nslookup) or after the "ANSWER SECTION:" (if using dig) to the list of IP addresses for your Linodes using the instructions in the previous section.

You may close this command prompt by typing exit, then pressing Enter or Return.

Cloudflare obfuscation

If you're still not seeing a match for the IP address using the instructions in the previous section, it's possible that your domain is using Cloudflare protection to obscure the IP address of your Linode.

To identify this possibility, open up another command prompt and use the IP address you received with the whois command. Replace with your actual IP address, then press Enter or Return to run this command:


You will see a long output from this command. Look over this output for any information that mentions Cloudflare, like this:

OrgName:        Cloudflare, Inc.

This indicates that you are using Cloudflare protection for this domain. You will need to log into your Cloudflare account through this page:

After doing so, you will need to identify the IP address corresponding to this domain. This guide from Cloudflare's help center can help you perform this identification:

Once you have the IP address, you can then attempt to match it to a Linode or NodeBalancer using the instructions above.

Internal administrative access

Now that you've identified the Linodes which your outside party must access, you can then set up credentials for this access to those Linodes. This will provide the customer access to the internal Linux environment of those Linodes.

As mentioned earlier, credentials to a specific Linode are entirely separate from Cloud Manager permissions. This may allow you to avoid any risk of exposing your services or account/billing information to the outside party.

In addition, these credentials are entirely separate between Linodes. This means that you will need to repeat these instructions for each Linode that the outside party must access.

Support scope

Before covering this setup, I'd like to state that this this setup falls outside of Linode's support scope since it covers the internal configuration of your Linode services. We aren't able to log into your Linode on your behalf, even if you provide us credentials, so we have limited visibility into your Linode.

However, the Community Questions site exists in part to cover answers to issues outside of Linode's support scope, hence us publishing this guide here :)

Setting up these permissions

First, you will need to log into your Linode as a user who has administrative permissions. Generally, you can achieve this using the LISH console on the Linode's main page.

Logging into your Linode

The Lish console will ask you for a user name, after which you will then press Enter or Return. You will then be asked for a password. This password won't show up on the screen, even with filler characters like *, but your Linode is accepting your input. Simply type out the password and press Enter to log in.

You can also use SSH to access your Linode with a command like this:

ssh <user>@<ip.address>

Here, you will specify the user name in the command itself. Be sure to replace <user> with your actual user name and <ip.address> with your Linode's actual IP address.

The command may ask you for the password when you press Enter or Return. This is most likely if you haven't set up an SSH key. As with the LISH console, this password won't appear on the screen, but your Linode is accepting the input and will check the password once you press Enter or Return again.

You may get a dialogue that looks like this:

The authenticity of host ' (' can't be established.
ECDSA key fingerprint is SHA256:AbCdEfGhIjKlMnOpQrStUvWxYz0a1B2c3D4e5F6g7H8.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

This generally just signifies that you've never connected to your Linode before. You should be able to type "yes" at this prompt and press Enter or Return, after which you may be asked for your password if you don't have a valid SSH key.

Don't know your user or password?

If you don't know what your Linode's user is, you can try the root user along with the root password you defined when first creating the Linode. The root user has complete control over a system.

If you don't know this password, you can reset the root password for your Linode. You may reset this root password from the "Settings" tab of your Linode's page.

If you reset the root password, you will need to first shut down your Linode, then power it back on after resetting the root password. You can then try to log into your Linode using the instructions above.

Creating a limited user for your outside party

Once you log in, I recommend creating a limited user for your client, then defining sudo access for this user. More information about how to do this is here:

sudo access will allow your client to temporarily gain full access over your system using root. This may be unavoidable depending on the sort of work they need to do. However, you can always change this root password again yourself. Later on, I will describe how to fully revoke their access permissions in case you ever must do so.

To identify the distribution of your Linode for the linked instructions, you can run the cat /etc/os-release command on your Linode to list out this information:

$ cat /etc/os-release
VERSION="20.04.1 LTS (Focal Fossa)"
PRETTY_NAME="Ubuntu 20.04.1 LTS"

For this example, you would then use the Ubuntu instructions.

Use SSH keys instead of passwords

With password logins enabled, following the above instructions should be sufficient to establish access to your Linode for your outside party. However, your client may also create an SSH key and pass it along to you for installation.

SSH keys represent a major enhancement of your Linode's security, allowing you to disable root- and password-based logins. This vastly reduce the potential for business-impacting outages due to attacks and compromises on your Linode.

Instructions to set up these SSH keys and disable other forms of access are located here:

Revoking internal administrative permissions

In case you need to revoke these permissions, this should be as simple as using the userdel command, replacing <client.user> with the actual username you defined for this client:

userdel <client.user>

This will delete the user, but preserve their home directory, perhaps in case you need it for archival purposes. If you'd like to delete this home directory, you may instead use this command format:

userdel -r <client.user>

This information is also available here:

I would also recommend resetting the root password on your Linode after performing this task. This should effectively ensure that your client is no longer able to access this Linode.

Cloud Manager access

The above instructions will give your outside party permissions to access your Linode's internal administrative interface. However, there is a chance that your outside party may need to access your Linode services within Cloud Manager itself.

If so, you will need to create a limited user for them. To do so, click your profile icon in the upper-right corner of Cloud Manager, then select the "Users & Grants" option. For your convenience, here is a direct link to that page:

On that page, you can click the "Add a User" button and provide both a username and an email address for that client. Most importantly, you will want to click the slider below these fields so that it reads "This user will have limited access to account features. This can be changed later.". This will ensure that the client only has access to the resources you designate.

After you create this limited user, they will be sent an email to create a login password, and you will then be able to define their permissions. It is probably most important that you set "Billing Access" to "None" to keep your financial information secure. "None" is the default option here, but it's worth verifying nonetheless.

Once you make this verification, you can then proceed with defining access permissions for your other services. There are three levels of permissions available: "None", "Read Only", and "Read-Write". "None" allows no access to the user for that service, not even to reveal the service's existence. "Read Only" will only allow the individual to know about the service's existence and view its information, while "Read-Write" will allow the customer to make changes to the services themselves.

Crucially, "Read-Write" access is necessary for your client to be able to use the LISH console. This will also allow them to reset the root password for your Linode. This is no different than them having internal sudo access to your Linode, but I think it's worth stating here explicitly nonetheless.

Revising or revoking Cloud Manager access

You may revise these permissions at any time by selecting the "Edit Permissions" link from the Users display in Cloud Manager:

From this page, you may also revoke these permissions at any time by simply deleting the user.

Additional resources

Our documentation has some additional resources which contain a wealth of supplementary information. Much of the information in this update was derived from these resources:

Having trouble with these instructions? There is help available!

If any of these instructions are beyond the scope of your expertise, feel free to follow up to this question! Our community would be happy to address your question. Depending on the technical expertise of your outside client, you may also want to ask them for their input.

Linode also has a Professional Services department available for hire. You may get a quote for this service and any other work you'd like done on your Linodes using the link below:

I hope you find these instructions helpful! This can be a pretty complicated topic, especially if you don't have any technical experience, so our community is happy to answer any questions you have about this subject.


Please enter an answer

You can mention users to notify them: @username

You can use Markdown to format your question. For more examples see the Markdown Cheatsheet.

> I’m a blockquote.

I’m a blockquote.

[I'm a link] (

I'm a link

**I am bold** I am bold

*I am italicized* I am italicized

Community Code of Conduct