Add the ability to tie SSH-agent & ssh-add to specific terminal...
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
- Issue type
- Feature
- Clarity
- Needs clarification
- Activity status
- Active
- Tech stack
- c, powershell
- Domain
- cli, operating-systems, security
Research direction
No source files, tests, or entry points are named. First clarify the supported Windows terminal profiles, policy controls, process or sandbox boundaries, and SSH-agent communication mechanism; completion would require an agreed design and tests for isolation and key access behavior.
Written by the indexing model from the issue text.
Description
Summary of the new feature / enhancement
I reckon with the mixed use of developing that goes in with windows and system administration. it could be a benefit to allow (with group policy overriding/disabling/enabling behavior) ssh-agent and ssh-add to be tied to terminal scope... so that instead of running ssh-agent and ssh-add as a global user scope... your terminal could be configured to launch 2 profiles; One that uses the user's ssh-agent daemon(as it currently is). OR to launch the shell sandboxing ssh-agent in the profile as a child process. This would also allow scripts running on the computer to not be able directly access all the keys in the global user scope...
Proposed technical implementation details (optional)
One could envision this as an extension of sudo or windows sandboxing, depending on your ecosystem, where the on systems where its enabled... the user global scope (path and sockets/pipes) would either be left open and accessible to all processes.. or the system can launch powershell with its handle controlling the child ssh-agent process (potentially using windows sandboxing or like it on the default pipe/socket path used by ssh-agent), allowing any exposed keys to be limited to that terminals scope
- Dominant language
- No language data
- Stars
- 8.3k
- Forks
- 822
- Avg merge
- 12m
- Merged PRs (30d)
- 1
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from PowerShell/Win32-OpenSSH
-
Area-ssh-agent Issue-Upstream Parity
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
PowerShell/Win32-OpenSSH#2458 · 1 reaction ·
-
Area-Authentication Area-Logging/Diagnostics Area-sshd Investigate Issue-Bug
Difficulty 4/5 3-5 days Newbie friendliness 48/100
PowerShell/Win32-OpenSSH#2466 · 1 comment · 1 reaction ·
-
Area-sshd Area-Terminal Investigate Issue-Regression
Difficulty 4/5 3-5 days Newbie friendliness 48/100
PowerShell/Win32-OpenSSH#2465 · 1 comment · 1 reaction ·
-
Area-ssh-agent Investigate
Difficulty 5/5 Over a week Newbie friendliness 25/100
PowerShell/Win32-OpenSSH#2460 · 1 reaction ·
-
User-defined environment variables referenced in the user PATH are not expanded in SSH sessionsOpenArea-sshd Investigate
Difficulty 4/5 3-5 days Newbie friendliness 68/100
PowerShell/Win32-OpenSSH#2456 · 1 reaction ·
All issues in PowerShell/Win32-OpenSSH
Similar issues
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
[Linux] --calibrate combined with --model silently falls through to plain re-setup (setup.py:4958)Open
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
vllm-project/speculators#1223 ·
Maintainers usually reply within 2 days
-
Difficulty 1/5 Under an hour Newbie friendliness 88/100
lundybernard/battodo#105 ·
Maintainers usually reply within 2 days
-
bug tool-calls
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Maintainers usually reply within 1 day