Frequently Asked Questions

Contents

  1. General
    1. How does Shellvault work?
    2. Why is Shellvault better than using SSH from my machine?
    3. Why is Shellvault not better than using SSH from my machine?
    4. I've found a bug. What do I do?
  2. Security & Privacy
    1. How do you save my credentials if you don't store my server password?
    2. Does Shellvault store my server password if I used it to get set up?
    3. Isn't sharing my SSH keys with any third party service dangerous?
    4. Why do I need a full keypair instead of just a public key?
    5. How does Shellvault store my keys and other data, like my Shellvault login password?
    6. How can I revoke all Shellvault keys from my server?
    7. Can Shellvault read the commands I send? Are they logged?
  3. Usage & Troubleshooting
    1. Why do I see "Terminal has expired" after refreshing the page?
    2. Why do I keep seeing the Host Authenticity confirmation dialog?
    3. My password is correct, so why isn't my key being deployed?
    4. I have multiple browser tabs open. Why is the interface acting strangely?
    5. Pressing Ctrl-C to copy or Ctrl-V to paste doesn't work!
    6. How can I make the terminal faster, especially when tmux is active?

If you you're curious about something not explained here, please contact us at help@shellvault.io.

General

How does Shellvault work?

Shellvault uses a websocket to connect a client-side terminal emulator to an SSH process on Shellvault's servers. When you type a command, it goes through the websocket to the SSH client running on our servers, and the socket sends the response back to the terminal in your browser.

Why is Shellvault better than using SSH from my machine?

There are lots of great reasons to use Shellvault:

  • It takes less than a few minutes connect for the first time even if you're new to SSH.
  • You can access Shellvault from anywhere without setting up SSH on each computer.
  • Shellvault's terminal looks great and has tabbed panes for working on multiple servers at once.
  • You can try Shellvault for free for a day, and after that it only costs $5 per month (less than a cup of coffee!)

Why is Shellvault not better than using SSH from my machine?

There are a few reasons you might not want to use Shellvault:

  • Certain key combinations like Ctrl-W do not work in Shellvault (Ctrl-W closes the tab) because of browser limitations. You might not like Shellvault if you heavily use Ctrl-W, Ctrl-T, or Ctrl-N (although our terminal lets you remap Ctrl-Backspace to Ctrl-W, which helps a lot).
  • The Shellvault interface can be a bit slower than a native terminal, especially with ncurses applications that redraw the whole screen. You can use mosh instead of ssh to help alleviate this.
  • We do our best to keep your data secure, but you may still not trust our security (or us). Using Shellvault trades some security for its convenience -- if you're not sure about it, feel free to contact us with questions at help@shellvault.io.

I've found a bug. What do I do?

For security-related bugs, please email us immediately at security@shellvault.io. If you have found a critical security bug (on par with remote code execution, database leakage, etc.), we will pay you a bounty of up to $500, depending on severity. We take security very seriously.

For cosmetic and usage bugs, please email us at bugs@shellvault.io.

Security & Privacy

How do you save my credentials if you don't store my server password?

Shellvault exclusively supports SSH keypairs, a secure connection method that's based on public-key encryption. You can create as many keypairs as you want with Shellvault, set them up on a server, and revoke them later, all without revealing your server password. See Getting Started for more.

Does Shellvault store my server password if I used it to get set up?

No. We use your password to set up an SSH key for you, but we don't log or store it anywhere.

That said, it's a good habit to not trust anyone with your server passwords. You can read about how to use Shellvault without exposing your password on our Security Best Practices and Getting Started pages.

Isn't sharing my SSH keys with any third party service dangerous?

Yes. We don't want you to use your pre-existing SSH keypairs with Shellvault, for the same reasons we encourage you to keep your password to yourself.

An SSH keypair is made up of a public key (id_rsa.pub) and a private key (id_rsa). Sharing your public key is ok, but you should never share your private key (from the file id_rsa) with anyone. Instead, we've made it easy to create new Shellvault-specific keypairs (or upload your own fresh keypair) and authorize them on your remote server. See the Getting Started page for more.

Why do I need a full keypair instead of just a public key?

Shellvault executes an SSH process on your behalf, just like PuTTY or a local SSH client. The public and private key parts of a keypair are cryptographically coupled, so using SSH with a private key "proves" that you are the owner of a public key authorized on your server. Shellvault can generate both keys for you.

How does Shellvault store my keys and other data, like my Shellvault login password?

Shellvault runs on Amazon Web Services, a well-known secure cloud service provider. Our databases are inaccessible from non-internal servers, and all critical data is stored encrypted.

  • Your public and private keys are encrypted at-rest with the AES-256-CBC cipher. They are only decrypted when you use them. In the event of a database leak, an attacker won't be able to access your keys unless they also have your login password.

  • We salt and hash your Shellvault login password with standard best practices for password storage (bcrypt).

  • We don't store SSH connection logs or server passwords, ever.

  • Stripe processes all of our payments. We don't store financial info ourselves.

How can I revoke all Shellvault keys from my server?

Key authorization is tracked in ~/.ssh/authorized_keys. You can quickly revoke all Shellvault access by removing Shellvault-owned keys from that file.

The Revoke dialog on the Shellvault servers list provides a copyable command that will revoke the key for you. You can also edit ~/.ssh/authorized_keys yourself.

Each line in authorized_keys is one key, and shellvault-generated keys all contain the term shellvault. You can delete all of them like so, even from a Shellvault terminal connected to your server:

$ sed -i.bak '/shellvault/d' ~/.ssh/authorized_keys

Running sed with the flag -i.bak creates the backup file ~/.ssh/authorized_keys.bak. You can rm it or keep it for later, in case something bad happens to authorized_keys.

Can Shellvault read the commands I send? Are they logged?

Shellvault does "see" your terminal commands: when you send a command to the browser, our server relays the commands to an ssh process, then sends the response back to your browser. Since our server has to relay your commands somehow, we can't design the service without this.

However, we do NOT log, parse, track, or record your commands or their output in any way except to send them between you and the SSH process running on our servers (i.e. the service we provide).

If you have concerns, would like to know more, or can suggest a way to improve our users' security, contact us at help@shellvault.io.

Usage & Troubleshooting

Why do I see "Terminal has expired" after refreshing the page?

Shellvault keeps your SSH session alive for a few moments after you leave the page so that an accidental browser refresh won't terminate your active connection. If you don't return to the terminal after that period, Shellvault automatically closes the connection. When you open the terminal page again, you will reconnect to the server, but your previous session will be gone and you'll see a notification.

Furthermore, the terminal library we use cannot load terminals if their containing tab pane hasn't appeared on the browser screen yet. When the page refreshes, Shellvault has to wait until you switch to those tabs to reload the terminal.

If you're doing critical work that would be lost if your session disconnects, we strongly recommend you use tmux or screen, which both let you re-attach to a terminal session if your connection gets dropped.

Why do I keep seeing the Host Authenticity confirmation dialog?

SSH keeps track of a digital "fingerprint" for each server it connects to. When you connect again, SSH checks to see if the server's fingerprint matches what it remembers. This helps avoid situations where a new, nefarious server pretends to be your new server.

If you see the warning more than once when connecting for the first time, it may just be because the terminal scrollback still has the notification text in it. You shouldn't get notified again once the scrollback clears and you reconnect again.

If your server's fingerprint changes, however, you see the dialog (or a similar one) more than once. If the server really did change, you can dismiss the warnings by cloning the old server and connecting to that one instead, which will let you remember the new fingerprint. If you have any problems, let us know at help@shellvault.io.

My password is correct, so why isn't my key being deployed?

Your server may not be configured to allow password-based access. If that's the case, You'll have to configure the SSH server to allow password authentication (PasswordAuthentication yes) or import a pre-configured keypair to use instead.

I have multiple browser tabs open. Why is the interface acting strangely?

Shellvault only works in one browser tab at the moment. Use multiple internal tabs instead (click the + button at the top-right of the page).

Pressing Ctrl-C to copy or Ctrl-V to paste doesn't work!

We haven't written custom handling for copy and paste yet. For now, try these key combinations:

  • To copy: Right-click and select Copy in the browser popup
  • To paste: Shift+Insert or Ctrl-Alt-V

How can I make the terminal faster, especially when tmux is active?

tmux redraws the entire terminal screen, so using tmux sends a lot more data between your browser and our server, which can make your connection feel much slower. Here are some things you can do to try and get better performance:

  • Try toggling the Buffer terminal option on the Shellvault Options page and see if it makes a difference.
  • Try editing your server in the Shellvault Servers page to use mosh instead of ssh. Mosh may help the terminal feel snappier, especially if your SSH server is far away from our servers (which are in us-east).
  • Try using GNU screen instead of tmux, and see if it makes any difference. screen draws a bit less, which may help Shellvault's performance.
  • Try refreshing the page. You'll have to swap to all of your open tabs to reload their terminals, but refreshing may help smooth things out.