triton ssh command not aware of "ubuntu" login for ubuntu-certified images about node-triton HOT 27 CLOSED

I'm not sure how this can be handled, but if adding some metadata to the image would simplify things, I can make that happen.

from node-triton.

Heh, was just discussing this in a separate email thread. From that thread:

triton ssh: cannot hardcode root user when using certified ubuntu, also user
may also want to create other ssh users; may have to allow to specify
overriding login user name

FWIW the usual "-l LOGIN" ssh option works, e.g.:

triton -J us-east-1 ssh trenttest0 -l ubuntu

However I think this would be nice:

triton -J us-east-1 ssh ubuntu@trenttest0

As to if/how we could hardcode that... do we just want triton to
hardcode that for images with "ubuntu-certified" in the name? Kinda
cludgy. My old 'smrt' tool did do this kludge.

from node-triton.

Another reason I hate this kludge: We don't always have image name so can't know it is "ubuntu-certified-*" without fetching the image info via "GetImage". It would suck to add that delay for all 'triton ssh ...' calls. In fact, that's a non-starter.

I think perhaps ubuntu-certified users just need to suffer here.

We could have some tritron CLI config var for a default ssh login to use for all triton ssh calls.

from node-triton.

Yeah, forget the kludge. I think as long as there's a way for a user to manually override the login user, that would be good enough. Maybe something like a user flag?:

triton ssh -u ubuntu ubuntu-certified-instance

from node-triton.

If we choose the username flag route, it should probably be '-l' to mirror what ssh uses.

from node-triton.

@chorrell @pfmooney see @trentm 's earlier post... as-is triton supports passing arguments to ssh in raw form... so

triton ssh foo -l dave whoami

results in effectively

ssh -l root 1.2.3.4 -l dave whoami

it's ugly, but the second -l argument to ssh will win.

It would be nice for ubuntu logins to work out of the box though, but it's hard without arbitrarily hardcoding login names.

from node-triton.

@bahamas10 Great. I just didn't want additional flags confounding the situation.

from node-triton.

@pfmooney ack. we don't have to add our own flag to support logins because we can pass them directly to ssh, but if we did I would make sure it was -l to match ssh :)

If we can't figure out a good way to determine this information, i'll add documentation to the command output to explain this.

from node-triton.

I want to add this in too:

This works:

$ triton ssh instance -l user

But this doesn't:

$ triton ssh -l user instance
triton ssh: error (Option): unknown option: "-l"

My brain is stuck fast in the habit of the later, so it was a bit disorienting for me at first. I'm ok with that if it makes parsing overly difficult permitting it in front. If we do though, it might encourage people to try/want all ssh options available before the instance name. But in either case, user@instance should work.

from node-triton.

What's the data source for what the default username is? @chorrell asked "if adding some metadata to the image would simplify things, I can make that happen," and it seems like a smart idea generally.

I'm especially curious because I was updating the docs on how to ssh to an instance and couldn't find where this question could be answered in the API. The portal shows the right user, but I'm not clear what data source it uses.

from node-triton.

It's usually just root, but on most (all?) images admin works too. Ubuntu Certified images are different because of Canonical's certification.

from node-triton.

@misterbisson the "default_user" tag only exists on an image if non-root:

oyd:~ ll$ export SDC_URL=https://us-east-3.api.joyent.com
oyd:~ ll$ sdc-getimage 47c62485-9803-4d81-9023-c987f5100aff
{
  "id": "47c62485-9803-4d81-9023-c987f5100aff",
  "name": "ubuntu-certified-14.10",
  "version": "20141022.3",
  "os": "linux",
...
  "tags": {
    "default_user": "ubuntu",
    "role": "os"
  },
...

from node-triton.

the "default_user" tag only exists on an image if non-root

From a naive user's perspective, it would be great to have it in every case, not just the exceptions, but thank you for pointing it out.

from node-triton.

From a naive user's perspective, it would be great to have it in every case, not just the exceptions, but thank you for pointing it out.

I agree, I previously made the argument when we added LX-brand images in internal ticket IMAGE-712.

from node-triton.

Unfortunately I don't think IMAGE-712 would help here. We don't want 'triton ssh ...' to have to lookup the image object to ssh in.

@bahamas10 Would be nice to support triton ssh ubuntu@myububox ... too.

Also agree that we should try to support triton ssh -l LOGIN myububox as @bahamat requested. Implementation-wise, we don't want to have to add every SSH option as a dashdash option on "do_ssh" here. I should look into a way to tell node-cmdln/dashdash to allow unknown options... that can just be passed through to ssh.

from node-triton.

I suppose we could have triton ssh have to GetImage to know image details (like the tags.default_user). It could cache that aggressively so that typically it isn't refetching.

from node-triton.

@trentm you can hate me for asking my somewhat off-topic questions in this thread, but I'm definitely not making any demands about how triton ssh is implemented.

from node-triton.

Casey, it is all good

On Aug 31, 2015, at 5:00 PM, Casey Bisson [email protected] wrote:

@trentm you can hate me for asking my questions in this thread, but I'm definitely not making any demands about how triton ssh is implemented.

—
Reply to this email directly or view it on GitHub.

from node-triton.

For now let's just update the help text to expose the -l option. We can save other improvements for later. At this time, I'd suggest to incorporate only feedback that would cause us to: 1) change the request payload, or 2) drop anything from response payload, before opening up node-triton to all.

from node-triton.

@trentm you can hate me for asking my somewhat off-topic questions in this thread

Likewise. I'm just traveling down some side roads.

from node-triton.

Supported added in c4f85db for:

triton ssh user@id

Adding possible support in the future for arguments to be passed from triton ssh to ssh won't be as easy... for example:

triton ssh id -l user -v -N

Everything after id will be passed directly to ssh on the system, but:

triton ssh -l user -v -N id

triton will complain about unknown options passed to triton ssh. If we allow arbitrary command line options after triton ssh to be passed directly to ssh, we will have to manually parse them as well to find the instance name. In the above example, triton will need to know to ignore -l user, and -v, and -N, in order to find id, and get the primary IP address for it.

I would like for this to work, and I would also like triton to be "smart" in the sense that it can automatically infer the username to use.. but I don't know if it can be implemented in a clean way unfortunately.

from node-triton.

I might be able to get triton ssh SSH_OPTIONS host MOAR_SSH_OPTIONS working using dashdash's allowUnknown.

from node-triton.

@trentm my main concern is that dashdash won't be able to extract the instance name... for example

triton ssh -v -l dave my-machine-1 -N

The idea is to execute ssh -v -l dave -N <ip address> but the problem is finding the instance name in the command line arguments. How will dashdash know that my-machine-1 is special and should be extracted from the list of arguments?

from node-triton.

Update for others: @bahamas10 and discussed it a bit and he's right. Pulling out "my-machine-1" in the example above in general means rewriting the full set of ssh options as dashdash options for parsing. I'm not sure if there is enough variance in ssh options on various platforms that that runs into surprises.

I could probably make a pretty good lie so that interspersed ssh options would work, but there would like still be the odd surprise. Punting on that part for now.

from node-triton.

I can still see value in this issue being open

1

I would like triton ssh [OPTIONS] instance [MORE_OPTIONS] to work

2

It would be cool if triton ssh could infer the username based on a tag, or some form of metadata easily retrieved without adding serious overhead

from node-triton.

I put up a change that handles this using the image cache. In addition, I extended the TTL to one hour when retrieving specific images. On my system this results in no measurable performance difference for this change as long as the json file is in the cache

from node-triton.

This'll be in 5.0.0 when we release that. Thanks, @dillona!

from node-triton.