dropbear and .ssh/authorized_keys

Discussion in 'Tomato Firmware' started by wrlee, Jul 31, 2009.

  1. wrlee

    wrlee Addicted to LI Member

    I've seen a lot of issues with getting ~/.ssh/authorized_keys to work with dropbear. None of the solutions I've seen work. The suggestion to move it to /etc/dropbear also does not work.

    The problem is that every time Tomato restarts dropbear, the authorized_keys file is overwritten. If you update that file while dropbear is running, then it will continue to work as expected, but that is a hassle.

    The solution with Tomato is to copy the contents of that file to the web interface as the "Authorized Keys" value of the Administration->Admin Access->SSH Daemon settings. (Tomato actually creates/overwrites the ~/.ssh/authorized_keys file with that value each time it restarts SSH).

    Hope this helps, it took me hours to figure this out.

  2. fyellin

    fyellin LI Guru Member

    You should have asked the forum, first. Someone could have saved you hours of time.

    Tomato is designed that you can configure almost everything using the GUI. If you discover you need to telnet/ssh to the device, you're probably doing something wrong. Obviously, there are some exceptions to this, but in general, most things really are designed to be easy.

    You confused yourself by knowing too much about how to configure "ssh" in other environments.
  3. rhester72

    rhester72 Network Guru Member

    You can also add the authorized pubkeys via the GUI, which are saved to NVRAM and reloaded after reboot, which is what I think you're trying to achieve.

    Storing a *private* key and using it is another matter (but can also be solved).

  4. wrlee

    wrlee Addicted to LI Member

    Thanks for the encouragement. A lot of times forum regulars get upset if someone asks a question that has been addressed several times, so I did a search first and found consistent answers but whose that did not match my experience. The hours of time were spent trying to figure out what went wrong, then being misdirected by incorrect answers. (It probably wasn't really hours... I was doing a lot of other things at the same time :) )

    Hmmm... maybe... I'm a bit fuzzy on all the pubkey/privkey stuff and what needs to be where. My goal was to allow password-less login, but I may have slightly diminished security, in the process, by the way I have distributed the keys.

    Thanks for your input, both of you.
  5. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    I think you have it down pretty well. What rhester72 was suggesting was exactly what you indicated you did in your first post: put the authorized public keys in the "Authorized Keys" field in the GUI.
    Quite the opposite. PKI is considered quite a bit more secure than password-only logins.
  6. fyellin

    fyellin LI Guru Member

    Just to elaborate on what SgtPepperKSU said. The information in .ssh/authorized_keys is completely non-confidential. You should, of course, make sure that no one can modify the file and change the authorizations, but it doesn't matter who reads it. Publish it in the New York Times! The secret information is what's encrypted in your .ssh/identity file, and that information never leaves your computer, even when you're logging in.

    Even though I understand the math, Public Key encryption still sometimes feels like magic.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice