finally got dev hterm going on my Samsung ChromeBook

[Jef Poskanzer]

I finally managed to get the dev version of the ChromeBook ssh app installed.  This is the one that runs on my Samsung ChromeBook with the non-intel CPU.

Pros:
- It runs.
- I no longer have to type my username and hostname every time, I just hit return.
- It runs in a window instead of in a browser tab, so I can type ^W without it asking whether I want my tab to go away.

Cons:
- I haven't gotten key-based login to work so I still have to type my password every time.
- And "every time" is still way more often than it should be, because ChromeOS still doesn't have a "don't go to sleep when you're on wall current" option.  Not ssh's fault, but ssh is the only app that runs into this.

[Steev Klimaszewski]

You need to put both your private and pub key on the machine in question, and then use the "import" option for both the private, and public key. (so id_rsa and id_rsa.pub as an example) for key-based logins to work.

[Jef Poskanzer]

On Monday, March 18, 2013 9:26:30 AM UTC-7, Steev Klimaszewski wrote:

You need to put both your private and pub key on the machine in question, and then use the "import" option for both the private, and public key. (so id_rsa and id_rsa.pub as an example) for key-based logins to work.

Yes, that's what the directions said and that's what I did.  Had to do a rename operation on the private key file because Chrome's Save As function insisted on adding a .txt extension.  But once it was all installed and imported and selected: no worky.  It asks for my key passphrase and then still asks for a login password.

Also, even though I used an empty passphrase when I created the key, hterm still asks me for a passphrase.  Other ssh programs know to try decrypting with an empty passphrase first and see if it works, before asking.  This seems like it would be pretty easy to fix in hterm.

[Shane McCarron]

It doesn't ask me to enter a keyphrase for what it is worth.  I have had no problems using either DSA or RSA keys.

--
Shane McCarron
halin...@gmail.com

[Jef Poskanzer]

On Monday, March 18, 2013 10:27:55 AM UTC-7, Shane McCarron wrote:

It doesn't ask me to enter a keyphrase for what it is worth.  I have had no problems using either DSA or RSA keys

Ok, that's good to know. So maybe those two problems I'm seeing are connected: it's asking for a passphrase when it shouldn't, and then asking for a password when it shouldn't, because something is not right with the keypair I installed.

Is there some flag I can set to get helpful diagnostic messages?

[Robert Ginda]

Secure Shell uses OpenSSH under the hood.  You can add "-v" to the SSH Arguments field to get some extra debug logging.  You can also try opening the JS Console (ctrl-shift-j) and see if there are any error messages there.

Did you select the keypair after importing it?  It's not automatically selected after importing.

Rob.

[Jef Poskanzer]

On Monday, March 18, 2013 11:11:55 AM UTC-7, Robert Ginda wrote:

Did you select the keypair after importing it?  It's not automatically selected after importing.

Si.

Secure Shell uses OpenSSH under the hood.  You can add "-v" to the SSH Arguments field to get some extra debug logging.

Excellent.  Here's the relevant portion:

debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: /.ssh/cb
debug1: key_parse_private_pem: PEM_read_PrivateKey failed
debug1: read PEM private key done: type <unknown>
Enter passphrase for key '/.ssh/cb': [I type return]
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: password
j...@acme.com's password: [I type the password]
debug1: Enabling compression at level 6.
debug1: Authentication succeeded (password).

debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: /.ssh/cb
debug1: key_parse_private_pem: PEM_read_PrivateKey failed
debug1: read PEM private key done: type <unknown>
Enter passphrase for key '/.ssh/cb': 
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: password
j...@acme.com's password: 
debug1: Enabling compression at level 6.
debug1: Authentication succeeded (password).

debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: /.ssh/cb
debug1: key_parse_private_pem: PEM_read_PrivateKey failed
debug1: read PEM private key done: type <unknown>
Enter passphrase for key '/.ssh/cb': 
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: password
j...@acme.com's password: 
debug1: Enabling compression at level 6.
debug1: Authentication succeeded (password).

So indeed something is wrong with the keypair I imported.  I'll try making/installing/importing another one. 

[Jef Poskanzer]

No idea why the ssh -v excerpt got pasted in three times.  Whatever.

[Robert Ginda]

From the JS console you can type something like...

lib.fs.readFile(term_.command.fileSystem_.root, '/.ssh/cb', function(f) { console.log(f) })

...and it'll dump the contents of the key to the console.

[Robert Ginda]

And as far as the whole going to sleep thing goes...

There's an extension for that: https://chrome.google.com/webstore/detail/keep-awake-extension/bijihlabcfdnabacffofojgmehjdielb?hl=en.  The caveat is that it keeps your screen awake too.  There's work happening to make the API more granular.  There's and there's work happening on a "Docked mode" which will allow you to keep the machine from sleeping when it's tethered: https://code.google.com/p/chromium-os/issues/detail?id=36262

Rob.

[Jef Poskanzer]

On Monday, March 18, 2013 11:48:46 AM UTC-7, Robert Ginda wrote:

From the JS console you can type something like...

lib.fs.readFile(term_.command.fileSystem_.root, '/.ssh/cb', function(f) { console.log(f) })

...and it'll dump the contents of the key to the console.

Ok, that was productive.  Instead of a plain old key file, it's a fakey email message with the key file as a MIME attachment.  No doubt this is because of the way I transferred the files from my Unix box to the ChromeBook: stuck them on the web server, sent Chrome to the pages, and used Save As.  I'll try to find a different way to transfer the key files. 

[Robert Ginda]

I'm surprised that didn't work.  You could try emailing them to yourself as an attachment, or use Google Drive or Dropbox.

One of these days we'll get scp working on Chromebooks.

Rob.

[Jef Poskanzer]

On Mon, Mar 18, 2013 at 12:19 PM, Jef Poskanzer <jef.po...@gmail.com> wrote:

Save As.

On Monday, March 18, 2013 12:23:06 PM UTC-7, Robert Ginda wrote: 

I'm surprised that didn't work.  You could try emailing them to yourself as an attachment, or use Google Drive or Dropbox.

Those are good suggestions but for various reasons none of them would work for me. I won't go into details, you don't care about my nearly retrocomputing environment.

But I did find a way: on the web server, I renamed the key files with a .jpg extension. That was enough to get Chrome to not be a Helpy Helperton and just save the files unmodified. Any binary-ish file type would have worked. Once they were saved on the ChromeBook I renamed them back to cb and cb.pub, imported them into hterm, and Bob's your uncle.  All working fine now.

Thanks for the debugging help!