Sequel-ace: Feature Request : Preference "default" location for SSH key ( i.e. ~/.ssh/id_rsa ) used for all connections unless other one specified for the specific connection?

[salvor-hardin]

Feature Request (seems easy!) :)

What about a "default" location for SSH key ( i.e. ~/.ssh/id_rsa ) so that is used for all connections unless other one specified for the specific connection?

I mean an option on preferences where the user still does have to navigate to the folder to select the file, but this will apply as default. for example in this menu?

This way we can setup this option ONCE and only change when is needed. Otherwise I'd have to do this for all of them...

_Originally posted by @salvor-hardin in https://github.com/Sequel-Ace/Sequel-Ace/issues/129#issuecomment-653116657_

Thanks.

[Synchro]

What about a "default" location for SSH key ( i.e. ~/.ssh/id_rsa ) so that is used for all connections unless other one specified for the specific connection?

This is exactly how OpenSSH works already - SA is overriding its behaviour and breaking it. I think it would be better (as in #159) to use the standard location and mechanism provided by OpensSSH to do this. I'm sure SA devs have enough to be getting on with rather than reinventing something that already works fine. I'm sure you can edit the config settings in SA's ssh_config file, but it would be far better to simply use the SSH config you've already got rather than maintaining a duplicate set buried inside an app bundle that may get trashed by updates.

[shawn-crigger]

I agree it should use OpenSSH's standard config file and not create it's own. I also noticed SA doesn't have permission to open the key files in ~/.ssh/

[Synchro]

Yes, I gathered from another thread that the sandboxing in Catalina (something SA has that SP does not) prevents access to files outside the app bundle without explicit permission – but I'd be far more comfortable with SA asking for that permission by default than substituting a config that doesn't work without giving an obvious error message. If I'd not read and understood the detail in the error log, I wouldn't have seen where this problem was. I happen to be running on an old MacBook with High Sierra, which doesn't have this limitation, but it still doesn't use the standard config, so everything breaks anyway.

If I have multiple apps that make use of SSH connections, it doesn't seem reasonable to require each one to have a copy of all the config and all the private keys – that seems to be more of a problem than the sandboxing was intended to solve. Can it perhaps use an ssh-agent process instead of accessing the config files directly?

[Jason-Morcos]

@shawn-crigger We don't have permission to access anything really without the user manually selecting it. That's the blessing and the curse of sandboxing.

@Synchro You're talking about the ssh config file not id file, please see #28. Sandboxing is complicated and we're working on enhancing the app. Please be patient. Sandboxing is designed to provide security, it doesn't really care if it's frustrating and increases complexity.

[Synchro]

Yes I realise that, but here the silently overridden ssh config file is causing it to pick up the wrong key. As far as I can see this is doing the opposite of what you say - decreasing complexity and (in the case of the example in #28 that generates a weak key) also reducing security.

I would much prefer an error, a connection failure, and the opportunity to give explicit permission to read config, or get the key from an ssh-agent, which as far as I can see is designed specifically to allow situations like this in a way that's managed securely and should not break sandboxing. Go ahead, inconvenience me!

[Jason-Morcos]

@Synchro Please keep conversation about the ssh config file request in issue #68. This issue is strictly about the requested enhancement to allow specifying a default ID RSA key that will be used for all connections by default. I had meant to reference #68 in my previous comment and instead referenced #28 by accident.

[Jason-Morcos]

@salvor-hardin Do you feel this issue is satisfied by being able to select a custom ssh config file which could set the ssh key for all connections?

https://sequel-ace.com/get-started/
see: "Sequel Ace doesn’t read my ~/.ssh/config parameters."

[wedi]

It might be a good idea to either show the used config in the SSH tab of a connection or add some kind of show once dialog to notify the user of the sandbox. I sticked to Sequel Pro for weeks because Sequel Ace hasn't used my ssh config. 🙄

I'm kind of hijacking this issue but it would be great to either offer a selection for the known hosts file or automatically use ~/.ssh/known_hosts when access is allowed. It's not even possible to reference ~/.ssh/known_hosts in the config file because the shell parameter overrides it.