Stories with Tag ssh

• Bcvi – run vi over a 'back-channel' (2010)

  permalink

  Posted: 2025-03-06 18:55:47

  Verbose tl;dr

  Bcvi allows running a full-screen vi editor session over a limited bandwidth or high-latency connection, such as a serial console or SSH connection with significant lag. It achieves this by using a "back-channel" to send screen updates efficiently. Instead of redrawing the entire screen for every change, bcvi only transmits the differences, leading to a significantly more responsive experience. This makes editing files remotely over constrained connections practical, providing a near-native vi experience even with limited bandwidth. The back-channel can be another SSH connection or even a separate serial port, providing flexibility in setup.

  The article "bcvi – run vi over a 'back-channel'" describes a novel approach to editing files remotely over a constrained network connection, specifically targeting situations where using tools like SSH or VNC might be impractical due to bandwidth limitations or latency issues. The core concept revolves around establishing a "back-channel" which is a separate, lower-bandwidth communication pathway alongside the primary channel being used for other purposes. This back-channel is then leveraged by a custom-designed program called bcvi to facilitate remote file editing using the familiar Vi editor interface.

  The article details the technical implementation of bcvi, explaining how it functions as a proxy between the user's local Vi instance and the remote file. Instead of transmitting the entire screen or file content back and forth, bcvi only exchanges minimal information necessary for Vi's operation. This includes keystrokes entered by the user, cursor movements, and changes to the file's buffer. The program achieves this efficiency by hooking into Vi's internal functions to intercept and process these events. On the remote end, a corresponding component of bcvi interprets the transmitted commands and applies them to the target file. The resulting changes are then relayed back to the local Vi instance, updating the user's view accordingly.

  The back-channel communication itself is handled through a separate program called bc, which utilizes User Datagram Protocol (UDP) for its transport. This choice is motivated by the desire to minimize overhead and tolerate occasional packet loss, making it suitable for unreliable network conditions. The bc program encapsulates the Vi-specific commands and data within UDP packets, ensuring efficient and robust transmission over the back-channel.

  The article highlights several advantages of using bcvi. The reduced bandwidth consumption makes it ideal for slow or intermittent connections. The responsiveness, despite potentially high latency, is attributed to the asynchronous nature of the communication. The familiarity of the Vi interface offers a comfortable and efficient editing experience for users already accustomed to Vi's commands and workflows. The article further emphasizes the portability of bcvi, stating its compatibility with various Unix-like systems and its reliance on readily available tools like Vi and UDP.

  Finally, the article discusses the potential use cases for bcvi, such as editing configuration files on embedded devices or managing files on remote servers with limited connectivity. It also touches upon the inherent limitations of the approach, acknowledging the potential impact of significant packet loss on the editing experience and the assumption that the remote system has a compatible version of Vi installed. The overall tone suggests that bcvi offers a practical and efficient solution for remote file editing in specific, constrained environments.

  • vi
  • vim
  • Text Editor
  • command-line
  • terminal
  • remote editing
  • back-channel
  • ssh
  • network
  • bcvi
  • 2010
  • unix
  • Linux
  • Software
  • Tool

  Summary of Comments ( 13 )
  https://news.ycombinator.com/item?id=43283814

  Verbose tl;dr

  Hacker News users discuss the cleverness and potential uses of bcvi, particularly for embedded systems debugging. Some express admiration for the ingenuity of using the back channel for editing, highlighting its usefulness when other methods are unavailable. Others question the practicality due to potential slowness and limitations, suggesting alternatives like ed. A few commenters reminisce about using similar techniques in the past, emphasizing the historical context of this approach within resource-constrained environments. Some discuss potential security implications, pointing out that the back channel could be vulnerable to manipulation. Overall, the comments appreciate the technical ingenuity while acknowledging the niche appeal of bcvi.

  The Hacker News post "Bcvi – run vi over a 'back-channel' (2010)" has several comments discussing the utility and implications of the bcvi tool.

  One commenter highlights the potential security risks of using such a tool, especially if the back channel isn't adequately secured. They express concern about inadvertently exposing sensitive information or granting unintended access to a system. This concern is echoed by another user who points out the inherent danger of trusting arbitrary escape sequences. They suggest that, while interesting, the approach presents a significant attack surface.

  Another commenter questions the practical applications of bcvi, wondering in what scenarios it would be genuinely useful. They acknowledge the cleverness of the concept but struggle to envision situations where it would be preferable to established methods of remote file editing. This skepticism is shared by a separate commenter who points out the existing availability of tools like sshfs which offer a more robust and secure way to edit remote files.

  Several commenters delve into the technical aspects of bcvi, discussing its implementation and potential limitations. One points out the challenge of handling interactive commands and the need for careful consideration of terminal emulation. Another user mentions the project's age and expresses curiosity about its current status and whether it's still actively maintained.

  A commenter recalls using a similar technique in the past, involving screen and vi, for editing files over a serial console. They describe the setup and the advantages it offered in their specific use case. This anecdote provides a practical example of a scenario where a back-channel editing approach could be beneficial.

  One commenter humorously suggests using netcat as a more straightforward alternative for editing remote files over a simple connection. While likely intended as a tongue-in-cheek suggestion, it highlights the potential simplicity of achieving similar functionality with readily available tools.

  Finally, a few comments express general appreciation for the cleverness and ingenuity of the bcvi concept, even if its practicality is debated. They acknowledge the value of exploring unconventional approaches to problem-solving.

• VSCode’s SSH agent is bananas

  permalink

  Posted: 2025-02-08 01:25:32

  Verbose tl;dr

  VS Code's remote SSH functionality can lead to unexpected and frustrating behavior due to its complex key management. The editor automatically adds keys to its internal SSH agent, potentially including keys you didn't intend to use for a particular connection. This often results in authentication failures, especially when using multiple keys for different servers. Even manually removing keys from the agent within VS Code doesn't reliably solve the issue because the editor might re-add them. The blog post recommends disabling VS Code's agent and using the system SSH agent instead for more predictable and manageable SSH connections.

  Kurt Mackey's blog post, "VSCode's SSH agent is bananas," delves into the complexities and potential pitfalls of Visual Studio Code's (VS Code) integrated Secure Shell (SSH) functionality, particularly regarding its interaction with SSH agents. Mackey begins by highlighting the convenience VS Code offers developers for connecting to remote servers via SSH, streamlining workflows by allowing direct code editing, debugging, and terminal access within the familiar VS Code environment.

  However, this apparent simplicity masks underlying intricacies related to SSH key management and agent forwarding. The blog post explains that VS Code employs its own internal SSH agent, distinct from the user's system-wide SSH agent. This design choice, while intended to provide a more contained and controlled environment, can lead to confusion and unexpected behavior, especially when working with multiple SSH keys and configurations across different projects.

  Mackey elucidates how VS Code's internal agent can inadvertently override the system agent, potentially causing connection failures or granting unintended access if not properly configured. He meticulously details the sequence of events that unfold during an SSH connection attempt through VS Code, illustrating how the VS Code agent attempts to authenticate first, even if a key matching the server's requirements is already loaded into the system agent. This behavior can be particularly problematic when using different key types or passphrases across different servers.

  The blog post emphasizes the challenges in troubleshooting these issues, as the interplay between VS Code's agent, the system agent, and the remote server can be difficult to discern. Mackey points out the lack of clear error messages or diagnostic tools within VS Code that would pinpoint the root cause of connection problems related to agent forwarding. This necessitates manual investigation of SSH configuration files, agent sockets, and environment variables.

  Mackey then dives into the technical details of how VS Code manages SSH connections, explaining the role of the vscode-ssh-extension and its interaction with the underlying SSH client libraries. He describes how the extension intercepts SSH requests and handles authentication through its internal agent, potentially leading to conflicts with user expectations based on their system-wide SSH configuration.

  Finally, the blog post offers potential solutions and workarounds for mitigating these challenges. Mackey suggests configuring VS Code to utilize the system SSH agent instead of its internal agent, allowing for centralized key management and consistent behavior across different applications. He also recommends carefully reviewing VS Code's SSH settings and understanding the implications of agent forwarding and key selection. Ultimately, Mackey advocates for greater clarity and transparency in VS Code's SSH implementation, empowering users with more control over their connection security and streamlining the debugging process for agent-related issues. He concludes by expressing the hope that these issues will be addressed in future versions of VS Code, making the SSH experience more predictable and less prone to unexpected behavior.

  • vscode
  • ssh
  • remote development
  • ssh agent
  • ssh forwarding
  • visual studio code
  • IDE
  • development tools
  • Debugging
  • Troubleshooting
  • connection issues
  • Security
  • performance

  Summary of Comments ( 448 )
  https://news.ycombinator.com/item?id=42979467

  Verbose tl;dr

  HN users generally agree that VS Code's remote SSH behavior is confusing and frustrating. Several commenters point out that the "agent forwarding" option doesn't work as expected, leading to issues with key-based authentication. Some suggest the core problem stems from VS Code's reliance on its own SSH implementation instead of leveraging the system's SSH, causing conflicts and unexpected behavior. Workarounds like using the Remote - SSH: Kill VS Code Server on Host... command or configuring VS Code to use the system SSH are mentioned, along with the observation that the VS Code team seems aware of the issues and is working on improvements. A few commenters share similar struggles with other IDEs and remote development tools, suggesting this isn't unique to VS Code.

  The Hacker News post "VSCode’s SSH agent is bananas" (linking to an article about VS Code's SSH agent behavior) generated a significant discussion with numerous comments exploring various facets of the issue.

  Several commenters corroborated the author's experience, sharing their own struggles with VS Code's SSH agent and expressing frustration with its unpredictable behavior. They described instances where the agent failed to connect properly, leading to authentication issues and workflow disruptions. Some suggested that the article highlighted a broader problem with complex SSH configurations and the difficulties in troubleshooting them.

  A recurring theme was the complexity of managing multiple SSH keys and configurations. Commenters discussed different approaches to key management, including dedicated SSH agents, agent forwarding, and tools like ssh-agent. Some advocated for simpler, more streamlined approaches to SSH configuration within VS Code.

  Some users defended VS Code's approach, suggesting that its SSH implementation offers flexibility and control, albeit with a learning curve. They pointed out that alternative editors and IDEs also face similar challenges with SSH management. Others offered specific troubleshooting tips and workarounds, such as configuring VS Code to use the system SSH agent or employing specific extensions to improve SSH integration.

  Several commenters delved into the technical details of SSH, explaining concepts like agent forwarding, key signing, and the differences between various SSH implementations. These technical discussions provided additional context for understanding the challenges outlined in the article.

  One particularly insightful comment highlighted the potential security implications of VS Code's SSH agent behavior, emphasizing the importance of proper key management and access control to prevent unauthorized access to remote systems.

  The conversation also touched upon the broader ecosystem of development tools and the challenges of integrating them seamlessly. Some commenters argued that the complexity of SSH configuration reflects a larger problem with the fragmented tooling landscape, calling for more standardized approaches to remote development workflows.

  Overall, the comments on the Hacker News post reflect a mix of frustration, technical analysis, and pragmatic solutions regarding VS Code's SSH agent behavior. The discussion provides a valuable resource for users struggling with similar issues and offers insights into the broader complexities of SSH management in modern development environments.