et not using ~/.ssh/config file about eternalterminal

[eskhool]

Hey @MisterTea, any ideas on this one? I have to keep specifying the user name on the destination server even though we have already provided it in the ssh config. Thanks again

[MisterTea]

Et only uses the ssh config for the initial ssh handshaking, but not for the et connection. Someone would have to write code inside et to read the ssh config. This isn't a high priority, so for now just make a bash script that connects and use the bash script to save the typing.

…

On Mon, May 8, 2017, 9:31 PM Anshuman Aggarwal ***@***.***> wrote: Hey @MisterTea <https://github.com/MisterTea>, any ideas on this one? I have to keep specifying the user name on the destination server even though we have already provided it in the ssh config. Thanks again — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#31 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AASuv9FGGoujIr4ej2J3xkbxcz44lGRdks5r3-whgaJpZM4NTrpG> .

[eskhool]

Just for my understanding, ET uses ssh for the initial ssh handshake (must be because my keyless authentication works...I assume even the username is being picked up by ssh from its own config).

After that initial connection if the ssh key is not required then the username should also not be?

[MisterTea]

Oh, that's a great point. With the new client/server architecture the username shouldn't be needed. I'll take a look at this tomorrow.

…

On Tue, May 9, 2017, 2:48 AM Anshuman Aggarwal ***@***.***> wrote: Just for my understanding, ET uses ssh for the initial ssh handshake (must be because my keyless authentication works...I assume even the username is being picked up by ssh from its own config). After that initial connection if the ssh key is not required then the username should also not be? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#31 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AASuv-DOUz2piH-AIsu81wWagU3nTXKSks5r4DZqgaJpZM4NTrpG> .

[eskhool]

@MisterTea, any luck with this change? Its not that hard to type the username but painful. Also FYI, the etserver hangs fairly often and then has to be manually killed before connecting again? Can help debug this if you need any traces.

[MisterTea]

@eskhool Make sure you are on 3.0.5. I have made a bunch of fixes to prevent the hanging you describe.

The past couple of weeks I was making a bunch of stability improvements, but I'll take a look this week.

[eskhool]

I am on the latest version released to homebrew and the PPA which appears to be 3.0.0 Is 3.0.5 to be installed from github direct?

[MisterTea]

@eskhool homebrew is on 3.0.0 so I need to update that, but most people are only using osx as a client so I haven't made it a priority.

You definitely want the server to be running 3.0.5, so the PPA is on 3.0.5

[eskhool]

@MisterTea, I think this thread got hijacked (by me for the hanging issue). Did you get a change to look at the username being optional issue? Thx

[MisterTea]

Hey @eskhool , actually when I thought about it: it doesn't save anything by removing the username option. You still need to pass the username to the launcher, which just passes it on to etclient. I could remove that second step but it will have no impact on the end-user because the username is still needed by the launcher for the initial connection.

[eskhool]

Actually I looked at the launcher and it seems to be using the username ($USER or $ETUSER) only to pass it to ssh to make the initial connection. Now a regular ssh client will parse its own ssh_config and get the username from there so it doesn't really need the username. Did I miss something

[eskhool]

Hey @MisterTea, I was able to get it working by just modifying the launcher. It looks like no more work needs to be done (atleast in the server or client code). It seems that if you just remove the user logic from et launcher and let the ssh client handle the picking of the username the connection works just fine.
PS: I haven't tried the multi user connection but don't see why that won't work based on the minor change I had to do in the et launcher.

All you need to do is the not force the present user as default in the bash launcher script (right at the top) and let the ssh client handle that for you. Sounds good?

[MisterTea]

Makes sense. You should be able to modify the script so if the user doesn't specify a username, then none is passed to ssh. But if the user does specify a username, then ssh will use the one specified. Thanks for investigating! Can you submit a pull request with the fix?

…

On Tue, Jun 20, 2017 at 12:01 AM Anshuman Aggarwal ***@***.***> wrote: Hey @MisterTea <https://github.com/mistertea>, I was able to get it working by just modifying the launcher. It looks like no more work needs to be done (atleast in the server or client code). It seems that if you just remove the user logic from et launcher and let the ssh client handle the picking of the username the connection works just fine. PS: I haven't tried the multi user connection but don't see why that won't work based on the minor change I had to do in the et launcher. All you need to do is the not force the present user as default in the bash launcher script (right at the top) and let the ssh client handle that for you. Sounds good? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#31 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AASuv4zyL8FWXWo-Z3Z2cPRH4Bmzef7Qks5sF24zgaJpZM4NTrpG> .

[eskhool]

#44

[MisterTea]

So do we still need to read from the ssh config file? I feel like we do for people using hostname aliases, etc..

[eskhool]

Ideally we should let ssh do its own reading from the config file and pass any parameters sent to et onwards verbatim.

We should parse the et command line parameters only for the ones et supports and pass the rest as is

[eskhool]

For my purposes this bug is closed for the moment