Chromebook: run a SSH server on Chrome OS

In this post, we’ll cover how to run a SSH server directly on Chrome OS (ie not into a Crouton chroot).

One of the first things I do on any machine (FreeBSD, Linux, Mac OS X or Windows) is to install, run and configure the SSH server. It’s always convenient to be able to scp from and to a computer, or to log in remotely. Even for workstations.

Chrome OS is a reasonable if minimal standard Linux installation offering access to iptables and sshd (and openvpn by the way), so it’s as easy to run sshd and to allow incoming traffic on port 22.


1. If it’s not already done, switch your chromebook in developer mode, so you can execute commands as root.

Do a backup of your data, as you’ll wipe your current Chrome OS partitions.

On most recent machines, restart in recovery mode (ESC + REFRESH + POWER), then when it boots, CTRL + D to enter the developer mode.

Hit enter to turn off OS verification. It will then restart. Now and everytime after, you’ll need to do a CTRL + D to boot.

It will then wipe your chromebook and reinstall a fresh Chrome OS version. The process takes 6 to 7 minutes.

Former machines require to use an hardware switch, generally located below the battery. Be gentle with this switch, it breaks easily.

2. Launch a console with the shorcut ctrl + alt + t, then write shell to open a full bash shell (if the shell command isn’t available, you aren’t in developer mode).

Become root with sudo su.

3. Setup SSH keys :

4. Run SSH:

5. Allow world to connect to port 22:

6. Add your public keys to ~chronos/.ssh/authorized_keys file. Authentication by password isn’t available.

7. You’re now able to log in from the world to your chromebook.


Andrew Sutherland, cr-48 chromium os ssh server, 14 January 2011.

CentOS wiki contributors, IPTables, CentOS wiki.

12 Replies to “Chromebook: run a SSH server on Chrome OS”

  1. I went through the instructions and I was able do chronos@localhost from the Chromebook but when I try from another computer it fails with the output bellow. Which public key should I using from the other computer?

    Warning: Permanently added ‘’ (RSA) to the list of known hosts.
    debug1: ssh_rsa_verify: signature correct
    debug1: SSH2_MSG_NEWKEYS sent
    debug1: expecting SSH2_MSG_NEWKEYS
    debug1: SSH2_MSG_NEWKEYS received
    debug1: Roaming not allowed by server
    debug1: SSH2_MSG_SERVICE_REQUEST sent
    debug1: SSH2_MSG_SERVICE_ACCEPT received
    debug1: Authentications that can continue: publickey,keyboard-interactive
    debug1: Next authentication method: publickey
    debug1: Trying private key: /Users/john/.ssh/id_rsa
    debug1: read PEM private key done: type RSA
    debug1: Authentications that can continue: publickey,keyboard-interactive
    debug1: Trying private key: /Users/john/.ssh/id_dsa
    debug1: Next authentication method: keyboard-interactive

  2. General recommended practice is to generate a set of keys in each machine you use.

    The private key so identifies you on a specific machine. This is especially convenient to revoke not used anymore keys (or react in incidents like physical thefts).

    So, what you need to do is to add the public key from the computer you connect from in /home/chronos/.ssh/authorized_keys using a format “cypher key comment” like this one:

    ecdsa-sha2-nistp256 AAAAE…. yourlogin@machine

    Or for a RSA key:

    ssh-rsa AAAAB3…. yourlogin@machine

    The computer you ssh from will try by default to use keys in a agent, or at standard paths (~/.ssh/id_rsa for example). You can force another path with ssh -i /path/to/public/private/key.

    SSH agent is probably the more convenient way if you need to connect from one machine to a series of other machines (including git remote repositories’ servers for example) and is broadly covered by

  3. I found I had to restart my machine after all this… possibly because I moved the authorized_keys file around before I got the name/path right, and possibly because sshd needed restarted.

    1. Because the file /etc/ssh/sshd_config contains PasswordAuthentication no.

      There is a tendency to consider authentication by password is a de facto deprecated SSH feature, and to strongly promote SSH keys instead.

      It’s efficient to prevent SSH brute force attacks, increase user comfort and security.

        1. Not a problem here. OpenSSH is already installed, and if /etc/sshd_config doesn’t suit you, you can run SSH through /usr/sbin/sshd -f /path/to/your/config/file. Some directories are writable like your home directory or like /mnt/stateful_partition for example.

  4. Once ssh installed, can i connect the device from external machine when the chromebook in normal mode and not in development mode.

    1. OpenSSH is already installed. You only need to start it. Alas, this start operation requires dev mode or a custom build (see other comment for your next question).

  5. How to manage a chromebook via SSH in normal mode ?

    Is there any other commands to know the hardware details of the machine other and vpd -l.

    I need to execute those commands in normal (non development mode), is it possible.

    1. This is a delicate question. Basically, running a SSH server means the system launches it or let you launch it. The normal mode doesn’t do the first and doesn’t allow the second: to launch it, you need a full shell to run the executable, and only dev mode provides that.

      What’s your root problem? Do you wish to offer at corporate level a Chromebook with SSH access or only for your own?

      In the first case, you could build a custom ChromiumOS image. You add SSH and other stuff you wish to generalize. But that’s not trivial to configure and create an huge burden of updates.

      In the second case, there is no real user experience drawback to the dev mode. The only thing is you need at each boot to press ctrl + D. As you use mainly hibernation closing the lid, you never really reboot it, excepted for updates or when a low battery incident occurs.

Leave a Reply

Your email address will not be published. Required fields are marked *