)]}'
{"specs/approved/ssh-ipmi-console.rst":[{"author":{"_account_id":4571,"name":"Steve Baker","email":"sbaker@redhat.com","username":"steve-stevebaker"},"change_message_id":"6106b16958cbb8446fb5980917390850f1cd832f","unresolved":true,"context_lines":[{"line_number":98,"context_line":"What other ways could we do this thing? Has someone else done this thing in"},{"line_number":99,"context_line":"another project? In another language? Why aren\u0027t we using those? This doesn\u0027t"},{"line_number":100,"context_line":"have to be a full literature review, but it should demonstrate that thought has"},{"line_number":101,"context_line":"been put into why the proposed solution is an appropriate one."},{"line_number":102,"context_line":""},{"line_number":103,"context_line":"Data model impact"},{"line_number":104,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"ee0063be_68e14ac6","line":101,"updated":"2025-04-09 00:41:46.000000000","message":"coincidentally I have just create a container based solution for taking ssh connections and proxying to something else in the backend[1] (in this case, telnet for my ancient switch). An alternative would be to go with a similar approach to graphical consoles, creating a container for an enabled console which runs sshd and exposes that as a connection to the end user. This allows deployment tools which integrate with graphical consoles to simply get ssh consoles too.\n\nA similar approach inside the container could be used here (authorized_keys based locked-down command) or sshd in the container can be configured to only run the desired command via sshd_config ForceCommand.\n\nWrapping this in a container per console would (further) mitigate the risk of users getting access to a shell on the conductor, which would be bad.\n\n[1] https://github.com/steveb/ssh2telnet","commit_id":"734a30bdef9bf5b17777e554eecbf06fa921caf8"}]}