Skip to content

Remote SSH bootstrapping support for read-only hosts #5607

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
ryansturmer opened this issue Oct 19, 2022 · 2 comments
Closed

Remote SSH bootstrapping support for read-only hosts #5607

ryansturmer opened this issue Oct 19, 2022 · 2 comments

Comments

@ryansturmer
Copy link

Is your feature request related to a problem? Please describe.
When I connect to a host using the SSH kitten that does not have a user-writable home directory (like many embedded targets) The connection actually drops and I have to reconnect manually with my SSH client (with no bootstrap/setup) - this means that I use the kitten to connect to some hosts and just ssh to connect to others which is sort of a fragmented experience.

Describe the solution you'd like
Ideally, I could specify using the configuration a location for bootstrap scripts on a per-host basis that would allow me to put the bootstrap files in a place that I know is writable. This is actually already supported with remote_dir but remote_dir is not allowed to resolve to anywhere outside of the home directory (such as /tmp which typically IS writable on such systems) -

Describe alternatives you've considered
another (less good) way to handle it would be at least to warn that the bootstrap couldn't be completed successfully but not drop the connection. This would at least give me the functionality I create myself by reconnecting without the kitten, but without my TERMINFO and stuff passing over, which is less than ideal.

Additional context
This is a change I can probably make myself relatively easily, but I wasn't sure about the rationale behind making remote_dir only resolvable into the home directory - I assume this is a security consideration or something, but there are other useful places to put the bootstrapping stuff, and if you work (as I do) on embedded targets frequently, sometimes configurations are all over the map and require special consideration.

@kovidgoyal
Copy link
Owner

There's no need for it not to be an absolute path, it doesn't really
give any security benefit, since one can easily just create a symlink to
leave $HOME. However, that wont solve your problem since terminfo needs
to be in ~/.terminfo for maximum compatibility as not all software
respects $TERMINFO. You could have the bootstrap script ignore failures
to copy terminfo I suppose.

@kovidgoyal
Copy link
Owner

And if you dont have a writeable home, just set HOME to something writeable in ssh.conf via the env directive.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants