View Single Post
Old 02-29-2016, 02:18 PM   #3
d0ugparker
Born empty--part full...
d0ugparker began at the beginning.
 
Posts: 8
Karma: 10
Join Date: Feb 2016
Location: Henderson, NV, USA
Device: Kindle Paperwhite
Notes on a successful SSH implementation on a PW3

(Admins: please add a Resolved tag to this thread.)

The READ-ME included in the zip file for USBNetwork is amazingly thorough, yet, IMHO, extremely succinct--so much so that it makes understanding it difficult after a dozen or more re-reads, but isn't that the case when we're all working here on our own and doing our own thing? (Admins: How can users recommend additions or changes to READ-ME files accompanying binaries?) I'm suggesting reading, then re-reading many, many times before the light turns on. I did this because I wanted to be a responsible, er, hacker, and not wanting to pester the admins or the power users who were getting the same questions from hundreds of end users. I'm saving my voice for when I really do need it.

As eschwartz mentioned, always be sure the latest binary is uploaded.

I was updated to 5.7.1.2, so the 0.21.N binary works on that Kindle version.

I used PuTTYgen.exe to generate my public and private keys. I used Notepad++ to generate the needed files, because it clearly tells me when I was in DOS or UNIX line ending mode (CR vs. LF vs. CRLF). The READ-ME is clear on always using UNIX EOLs, since everything is a UNIX shell.



I copied and pasted the public key from the area in PuTTYgen that states, duh, "Public key for pasting...."



Doing so kept the key on a single line.

This following image shows what the public key looks like when the "Save public key" button is clicked instead. Note the extra line feeds--not good:



Yeah, the SSH clients are probably smart enough to detect line feeds or not, but what if they don't know about CRs or LFs? Don't take a chance on dinkin' with 'em. Copying and pasting them puts everything on one line. Over. Done.

The Kindle's feedback area is a line at the bottom of the USBNetwork screen. It's tiny. Watch carefully, be prepared to read what flashes by very quickly, because you don't get a lot of time to grab all the information coming your way from the developers:



I went through my own, personal hell to figure out if the buttons display the state of each feature, or if they show what their changed state will be if selected:



They do not indicate the current state--they indicate what their state will change to if the button is clicked. If "Enable verbose mode" is showing, verbose mode is disabled. Duh, but some of the wording on other buttons is not as clear cut.

I used PuTTY.exe for the SSH client. IP addresses are not hard coded into PuTTY, but default values appear to be inserted from legacy development, and so that something will be in its proper place when you grab it (USBNetwork), install it, and try to connect to it. Documentation seems to show a 15 subnet (192.168.15.244, and 192.168.15.201). I've seen both IP addresses noted in the READ-ME and HELP docs.

Included in the setup files for USBNetwork, there's a config file that can be used to set the Kindle's IP address. In the config file, I set my Kindle's IP address to 192.168.1.114.

Doubling up on correct IP addresses, I used my Kindle's Settings > Wi-Fi Networks menu to get to the Advanced settings button, which allowed me to set its IP address, and all the other associated inputs needed:



Even though I was also setting the Kindle's IP address in USBNetwork's config file, I was doubling or tripling up on things to be sure that if I were to overwrite something, it'd overwrite with the same information. (Addendum: I was told by a power user that doing so was not a Good Thing™ to do. The two interfaces need separate IP addresses. I'm not sure which settings correspond to which interface, though. More addenda on that as they surface. Stay tuned!)

Some helpful pointers on using PuTTY.exe follow.

Your public key gets copied over on the Kindle. I saved mine locally on my Winders system as public.txt. On the Kindle, it needs to go in ./usbnet/etc/authorized_keys. Make sure it's in UNIX EOLs and my implementation worked when I put it all on one line. I know that nullifies each other, but IJS.

For security, always put a passphrase on your private key.

Here's where you set your path to your local, private key:



With USBNetwork binarly installed properly, with the public key on the Kindle, with a private key locally, with the IP address doubly-set to one of my choosing (192.168.1.114), I fired up PuTTY.exe and attempted a connection to the Kindle's SSH daemon.



You did turn the SSH daemon on, right?



One of two or three things happened on attempting to connect.
  1. Connection time out, or
  2. A server refused the key message, or
  3. A successful login and a passphrase needed.

A connection timeout is when you're furthest away from a successful login, but you don't get any hints on what's not right. Go back and re-read the notes above, and re-read the READ-ME file. Keep it simple. The solution is probably easier than you think it is.

A Server refused our key message is an indication of a failed communication between the two, but your keys are most likely not in the right format.



Use UNIX line endings--that was the biggest fail of mine, repeatedly.

A successful login comes in two, separate operations. The first notice I received was an obscure message about host keys not matching:



I looked at the rsa2 fingerprint listed in the security notice splash screen, but I couldn't identify it as coming from any key I had installed on the Kindle, so I'm not sure from where that message is being generated. So for now, I ignored it.

The buttons Yes, No, and Cancel are helpful, but they're not helpful. Read the details in the security notice for an explanation of each button's functions.

When I press Yes, which I would expect to allow me to connect with updated credentials, I don't connect.

When I press Cancel, of course, I abandon the connection attempt.

Confusingly, when I press No (which the text helpfully mentions will continue to connect but doesn't update the cache), I continue to step two of the SSH login process, where I'm asked for the private key's passphrase:



and upon successfully supplying the passphrase, I'm logged in through SSH:



Continue on with your regularly scheduled hacking.

Thanks to all the power users who contributed before me.

Dr Doug

Last edited by d0ugparker; 02-29-2016 at 05:59 PM. Reason: Changing some incorrect configuration made on IP addresses
d0ugparker is offline   Reply With Quote