guardian-agent
DomTerm
guardian-agent | DomTerm | |
---|---|---|
5 | 16 | |
433 | 357 | |
0.5% | - | |
0.0 | 8.0 | |
10 months ago | 3 months ago | |
Go | C++ | |
BSD 3-clause "New" or "Revised" License | GNU General Public License v3.0 or later |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
guardian-agent
-
Restricting SSH Agent Keys
https://github.com/StanfordSNR/guardian-agent
The problem basically is the current agent forwarding protocol doesn't have a way to reliably identify the source and remote host that can't be spoofed. guardian-agent tries to do that using some extra software, this linked SSH proposal is to add that to SSH but it will require software upgrades even to the sshd of the intermediate and remote hosts - it's not ideal that it can't just work out of the box - but I welcome this we just need to get it done now for later.
I frequently finding myself thinking about adding useful things to software I want to use now and go well it will be years before its on every host I use and can be used reliably. I have had this thought on and off for more than a decade. Ship some new stuff, it'l be great later :D
-
The pitfalls of using SSH-agent, or how to use an agent safely
ObPlug for Guardian Agent, which is basically "safe" ssh-agent forwarding (and works with Mosh and SSH): https://github.com/StanfordSNR/guardian-agent
The basic story is that ssh-agent really just exposes a primitive of "please sign this challenge," which is useful locally, but the protocol wasn't designed to be forwarded. If requests are coming from a semi-trusted intermediary host, the protocol doesn't tell the agent (a) what remote server is being authenticated to [i.e., who generated the challenge?], or (b) what command is going to be executed. It doesn't even really know (c) what (semi-trusted) host has forwarded the challenge?
Guardian Agent is a sort of hack that allows the agent to know (a), (b), and (c) before deciding whether to grant or deny the request, and you can set up policies like, "I'd like to allow `jump host x` to use to run "git pull" when talking to `git server y`, but that's it." The basic ssh-agent protocol just doesn't have enough info to be able to do something like that.
-
Mosh: The Mobile Shell
there is a fork with port forwarding support https://github.com/rinne/mosh and a PR with a long discussion https://github.com/mobile-shell/mosh/pull/696 on why it's not merged
you can compile them yourself or if you want to skip the step I recently set up GitHub actions to compile linux binaries of this [1][2], tested by a sample of 1 so no guarantees it works, was planning on doing a tap PR/tap of it at some point
also the official developers have been involved a project to solve this while improving the whole-agent approval things also https://github.com/StanfordSNR/guardian-agent , but I couldn't get it to work which is why I tried the fork and got that working
[1] https://github.com/gnyman/mosh/actions/runs/1068715036
-
AskReddit: is there such a thing as async SSH that allows for zero latency typing? (explanation in text)
‘mosh’ is amazing for this, although I had to stop using it years ago because it didn’t support key forwarding. Apparently, there’s now a solution for that: https://github.com/StanfordSNR/guardian-agent
DomTerm
-
Carapace: A multi-shell completion library and binary
Completion for program P should be written and maintained by the "owner" of program P - and installed with program P. This is of course difficult when there are many different "shells" that each have their own "language" for specifying completions. A multi-shell completion library can help with this problem.
To me it make sense that completion for program P should be handled by program P itself. That way, completions are unlikely to get out of sync with the application, and the completion handler can use the same option parser as the application. A way to do this is to use a special "hidden" switch to request completion.
Specifically the DomTerm terminal emulator (https://domterm.org) handles its own completions. Bash allows you to register a command that handles completions for some other command. The following tells bash that to handle completions for the domterm command it should call domterm with the magic "#complete-for-bash" option followed by the existing line and position.
complete -o nospace -C 'domterm "#complete-for-bash" "$COMP_LINE" "$COMP_POINT"' domterm
-
VT330/VT340 Sixel Graphics
Sixel has the one advantage of being mplemented in xterm and a modest number of other terminals. Otherwise, it's a pretty bad format: Inefficient. Unclear and inconsistently implemented specification. All images have to be a multiple fof 6 pixel rows, which may not align with either image height or character height.
Some terminal implement some other protocols, but attempts to specify a standard have failed. There are some tricky issues, such as: When does an image or part of an image get erased? Can you write text on top of an image and if so how are they aligned? What happens if you write an image on top of existing text? On top of an existing image? How does scrolling affect things? What happens to the image on window resize or zoom? Can you reliably update part of an image?
DomTerm (https://domterm.org) supports images in two ways:
-
Show HN: Rust+Svelte=Terminal
If interested in enhanced terminals, please take a look at DomTerm (https://domterm.org). It too optionally uses Tauri/Wry, though it can also also Electron, Qt, or a plain web-browser. You can embed images and rich text among other feayrures. DomTerm also has builtin tmux-like panes+tabs (mouse-draggable), detachable sessions, and a powerful "view" (selection) mode.
-
Solved: mouse click to position cursor in konsole
bash-preexec.sh and shell-integration.bash are copied from another terminal called DomTerm (that also offers click to position cursor) into ~/.local/share/DomTerm. Those files can be found here.
-
Mosh 1.4.0 Released
For people using or considering Mosh or Eternal Terminal: I'd love if you could try DomTerm (https://domterm.org). Specifically DomTerm's support for stable remote connections - see https://domterm.org/Remoting-over-ssh.html .
-
Ask HN: Is it still possible to live in a terminal?
DomTerm (https://domterm.org) isn't quite what you asked for: It only indirectly has a JavaScript console: Since its frontend is a browser engine, you can open up a JavaScript debugger.
-
TermKit: A Rich Graphical Terminal (2011)
DomTerm (https://domterm.org) attempts to provide similar possibilities as TermKit. However, it starts with the position that it should also (and perhaps first) be a fully-functional modern mostly-xterm-compatible terminal emulator. On top of that we add rich html text, images, logical structure, "shell integrayion", and more.
-
Quick roundup of bitmap graphics availability in free/open-source terminal emulators
DomTerm - JavaScript, Electron, Qt - Web browser, Linux (+ others?)
-
Using tree data structures to implement terminal split panes
DomTerm (https://domterm.org) uses the Golden Layout library (https://github.com/golden-layout/golden-layout). As far as I can tell, this does everything mentioned in the article. It also supports tabs, and you can also reposition terminal windows by dragging, neither of which I saw mentioned in the article. (I'm currently working on being able to drag between top-level windows. It sort-of-works, but only at the proof-of-concept level.)
-
Terminal support for Emoji – or why terminals don't like families
Please try DomTerm (https://domterm.org). The 2.9.4 AppImage (https://github.com/PerBothner/DomTerm/releases/tag/2.9.4) should have the needed support for grapheme clusters and hopefully work on reasonably up-to-date Linux systems. Of course there are more recent fixes and improvements if you don't mind building from source.
What are some alternatives?
Mosh - Mobile Shell
yaft - yet another framebuffer terminal
openssh-portable - Portable OpenSSH
mosh - Mobile Shell
muxile - Putting tmux on your mobile - Muxile is a tmux plugin that lets you control a running tmux session with your phone, no app needed.
tauri - Build smaller, faster, and more secure desktop applications with a web frontend.
wezterm - A GPU-accelerated cross-platform terminal emulator and multiplexer written by @wez and implemented in Rust
mac-ssh-confirm - Protect against SSH Agent Hijacking on Mac OS X with the ability to confirm agent identities prior to each use
nushell - A new type of shell
widecharwidth - public domain wcwidth implementation