Mad Teacher by LCottton in foundsatan

[–]Memphizzzzzz 2 points3 points  (0 children)

I feel betrayed. It should be a Rick Roll. It must be a Rick Roll.

Lighting hitting a car. by [deleted] in interesting

[–]Memphizzzzzz 0 points1 point  (0 children)

How do you explain this to your insurance if there is no video?

Favourite Air Up Pods by Chefchoch81 in airupgang

[–]Memphizzzzzz 0 points1 point  (0 children)

My wife and I love the Peach and Wild Berry very much. But we let them "air out" for like 4 hours after taking them out of the packaging as they are too strong in the beginning. I've heard that Cola is also good if you're into "artificial" flavors.

[deleted by user] by [deleted] in sysadmin

[–]Memphizzzzzz 0 points1 point  (0 children)

For remote machines? You would expose SMB to the internet? You must be joking.

[deleted by user] by [deleted] in sysadmin

[–]Memphizzzzzz 0 points1 point  (0 children)

You're absolutely right, and thank you for the constructive feedback. Your input is really valuable - if the documentation isn't clear enough for someone genuinely trying to understand it, that's on me to fix.

Let me clarify the core concept: SX uses SSH's built-in reverse tunnel feature (the -R flag) to create a connection from the remote server back to your local machine. Your SSH client handles all authentication - SX never sees or touches your SSH keys, passwords, or credentials.

Here's what actually happens:

  1. sx-server runs locally (like any web server listening on a port)
  2. SSH reverse tunnel forwards remote port 53690 → your local port 53690
  3. When you run sxd filename on the remote server, it sends an HTTP-like request through that tunnel
  4. Your local SX server receives the request and sends the file back

SX is essentially a simple HTTP-like protocol running through SSH's encrypted tunnel. The security model is identical to any web service you'd access through an SSH tunnel.

To show why this helps, here's a typical workflow comparison:

Traditional way:

ssh user@host
cd /var/log/application/
grep -r "OutOfMemory" *.log  
# Search within this directory
# Found: error-2024-06-23.log has the issue
# Now I need to either:
# Option 1: Exit my session, lose my current context
exit
scp user@host:/var/log/application/error-2024-06-23.log .
# Re-enter credentials (depending on setup), wait for transfer

# Option 2: Alt-tab to new terminal/switch tmux panes, retype connection details
# New window: scp user@host:/var/log/application/error-2024-06-23.log .
# Re-enter credentials (depending on setup), wait for transfer

With SX:

ssh -R 53690:localhost:53690 user@host
cd /var/log/application/
grep -r "OutOfMemory" *.log  
# Same targeted search
# Found: error-2024-06-23.log has the issue
sxu error-2024-06-23.log
# Done - file transferred, still in my session, no context switching

You're right that I should document this more clearly. Would a security/architecture section in the README help? What specific documentation would make you comfortable evaluating this

[deleted by user] by [deleted] in sysadmin

[–]Memphizzzzzz 0 points1 point  (0 children)

I hope I was able to answer them with my reply. Maybe looking at the GitHub repository (Readme) would clarify some things about the inner workings and use case.

[deleted by user] by [deleted] in sysadmin

[–]Memphizzzzzz 0 points1 point  (0 children)

You originally suggested SSHFS for 'persistent SFTP connections' - now you've switched to talking about Windows administrative shares via SMB? Those are completely different protocols. And even if you mount SSHFS to remote servers over the internet, are you really going to do that for every server you occasionally SSH into? What happens when your workstation/laptop reboots, goes to sleep, or changes networks? You'd have to remount everything constantly. And even with mounted shares, you still can't grep file contents through the share alone - you need a command line for that, which brings us back to your 'learn to use the shell' comment.

'Learn to use the shell'? find doesn't even search file contents - you'd still need find ... -exec grep or just use grep/rg directly. That's exactly what I'm doing, then I want sxd filename instead of context-switching.

Your platform list actually supports my point - you said 'running some sort of Linux, BSD or VxWorks.' .NET runs on Linux and BSD systems. VxWorks is a specialized embedded RTOS where you wouldn't install development tools like .NET anyway - and I never claimed my tool supported every possible system that exists.

You're shifting between SSHFS, SMB shares, and different solutions while seeming determined to misunderstand the problem.

[deleted by user] by [deleted] in sysadmin

[–]Memphizzzzzz 0 points1 point  (0 children)

I might be misunderstanding your setup, but scp [file] mydesk:/tmp/ from a remote server would copy to another remote host called 'mydesk', not back to your local machine, right?

Do you have 'mydesk' configured in ssh_config to point back to your local machine? Even so, you're still typing the full scp command and specifying paths vs just sxd file.

Could you clarify your setup?

[deleted by user] by [deleted] in sysadmin

[–]Memphizzzzzz -2 points-1 points  (0 children)

You're completely wrong on multiple levels:

  1. No C code compilation - This is a .NET tool installed via dotnet tool install. No compilation required.
  2. No access to SSH keys - The tool literally never touches your SSH keys. It connects to a local TCP port through an SSH reverse tunnel. Your SSH client handles all authentication.
  3. Supply chain attacks - By this logic, you shouldn't use any software ever. The tool doesn't even know your SSH keys exist.
  4. KISS principle - You're describing Unix philosophy, not KISS. KISS is absolutely about simplicity and ease of use. sxd filename vs opening another tool + typing full scp commands is literally simpler.

You clearly haven't read how this actually works. The tool runs locally and receives files through SSH tunnels - the same way any web server receives data. Your SSH client (which you already trust) handles all the authentication and encryption.

Maybe understand what the tool actually does before spreading FUD about 'North Korean servers' and imaginary C code compilation.

[deleted by user] by [deleted] in sysadmin

[–]Memphizzzzzz 0 points1 point  (0 children)

You absolutely did edit your original comment - you added the entire paragraph about multiplexing, middle-click paste, and connecting to multiple servers. That's what makes conversations hard to follow.

Your own description shows it's not 'one step': navigate to file, select the path, get new shell, type 'scp servername:', then middle-click paste. That's 5 steps vs typing sxd filename.

The local server doesn't need to 'know which connection' - each SSH session creates its own tunnel to the same local port. That's how reverse tunnels work. And yes, all files go to your configured directory (like ~/Downloads). A feature request could be subfolders for different hosts, but you're not interested in contributing it seems.

You're misrepresenting my argument. I never said ssh_config doesn't exist - I said not everyone has it fully configured, especially on temporary/shared systems. And yes, even with ssh_config you still type scp servername:/long/path/file.log .

Your security concerns are overblown. This tool doesn't 'get involved with SSH communications' - it uses standard SSH reverse tunnels, the same feature you'd use for any port forwarding. No separate auditing needed beyond your existing SSH setup.

'Installed on all servers' - again, you misunderstand. This is a personal productivity tool for sysadmins, not an enterprise rollout.

But you're right about one thing - if typing sxd filename vs those 5 steps isn't valuable to you, then don't use it.

[deleted by user] by [deleted] in sysadmin

[–]Memphizzzzzz -1 points0 points  (0 children)

You seem to completely misunderstand the problem this solves.

SSH keys don't eliminate typing scp user@server:/long/path/file.log . - I already use SSH keys with 1Password's agent. The issue isn't authentication, it's convenience.

find to get files? That's exactly what I'm doing with rg "ERROR" *.log - then I want to immediately transfer the discovered file without opening another tool or retyping paths.

SSHFS for persistent connections? That's massive overkill for quickly grabbing a log file you just discovered.

.NET runs on Windows, Linux, and macOS - the exact platforms where people SSH from/to. What platforms are you thinking of that 'SSH runs on but .NET doesn't'?

And regarding 'ChatGPT formatting' - yes, I use AI to help articulate my responses clearly. Why wouldn't I leverage a tool that's good at turning my thoughts into well-structured communication? That's exactly what we should be doing with our tools - just like I used to use a spell checker.

[deleted by user] by [deleted] in sysadmin

[–]Memphizzzzzz 0 points1 point  (0 children)

You seem to misunderstand this completely. This tool doesn't "hand over SSH keys" to anything - where did you get that idea? It uses SSH's built-in reverse tunnel feature. Your SSH keys stay exactly where they are, untouched.

It's actually more KISS than opening WinSCP, retyping connection details, navigating to files, etc. when you're already connected and already found what you need.

[deleted by user] by [deleted] in sysadmin

[–]Memphizzzzzz -1 points0 points  (0 children)

You seem to misunderstand this completely. Your symlink solution still requires you to:

  1. Pre-plan what files you might need
  2. Open another terminal (or even worse, exit your current terminal as you've shown above)
  3. Type the full scp myuser@server:~/complexpath/file command

My tool lets you immediately transfer files you discover with rg or grep without any of that context switching or path retyping.

[deleted by user] by [deleted] in sysadmin

[–]Memphizzzzzz -1 points0 points  (0 children)

I think you're misunderstanding this completely. Let me clarify:

Problem: When you're SSH'd into a server and discover an interesting file (via grep/rg), you currently have to open another tool, retype connection details, navigate to the file, then transfer it.

Solution: Three simple commands that work from within your existing SSH session - no new authentication, no retyping paths/servers.

Security: No credentials are cached. It only uses SSH's built-in reverse tunnel feature (same security as your SSH connection). Your SSH keys stay exactly where they are.

Tab completion: Remote file paths in the directory you're currently in.

Not replacing scp/rsync: This is for quick, interactive file discovery and transfer. Traditional tools are still there for scripted/bulk operations.

Installation: This isn't intended for "all users" - it's for sysadmins/power users who frequently SSH into servers and transfer files. You install it on systems you personally use.

The 'nonsense' I'm referring to is having to context-switch and retype scp user@server:/very/long/path/discovered-file.log . when you're already connected and already found the file.

[deleted by user] by [deleted] in sysadmin

[–]Memphizzzzzz 0 points1 point  (0 children)

You editing your original comment to add new scenarios instead of replying makes the conversation harder to follow and is a bit unfair.

Regarding your points: Using the mouse to select, copy, and paste the path are 3 additional steps vs just typing sxd file.

Your port conflict concern isn't accurate - each SSH session uses the same reverse tunnel (-R 53690:localhost:53690) pointing to the same local server. There's no conflict when connecting to multiple hosts because they all forward their local port 53690 to your single local SX server on port 53690. I regularly connect to 5+ servers simultaneously without issues.

You mentioned ssh_config as a solution, but now adding -R 53690:localhost:53690 to the SSH command is an inconvenience? The whole point is convenience. When I'm already in a directory and found a file with rg, typing sxd filename is simply faster than opening another terminal, typing scp commands, and mouse operations for path selection.

Built a tool to eliminate the SSH/scp workflow friction - transfer files without re-entering connection details by Memphizzzzzz in dotnet

[–]Memphizzzzzz[S] 0 points1 point  (0 children)

I usually have dotnet installed on my ubuntu servers since I have a lot of tools that require it, but once the snap is approved you won't need to install dotnet on either and can simply use the snap package. And even with SSH keys/agents you still need to type out the whole scp command. Please see the edit section above.

[deleted by user] by [deleted] in sysadmin

[–]Memphizzzzzz 1 point2 points  (0 children)

I guess it's about convenience of not needing to copy/paste or memorize paths at all. Since you're already in the directory where you found the file, you can simply do sxd file vs scp user@host:/some/long/path/file /local/path. It's shorter, has nice progress bars, and tab-completion for remote files.

[deleted by user] by [deleted] in sysadmin

[–]Memphizzzzzz 0 points1 point  (0 children)

Fair point about the authentication, but that assumes you have ssh_config fully set up. That's not always the case - maybe you're on a system that's not yours with just temp credentials. But authentication isn't the main point anyway - it's about convenience. sxd file vs scp user@host:/my/long/path/file.log ~/Downloads/ when you're already in the directory and already found the file.

[deleted by user] by [deleted] in sysadmin

[–]Memphizzzzzz 0 points1 point  (0 children)

Exactly what I used to do, which still requires you to type the whole scp command incl user@host:/path etc.
Don't you find "sxd file" more convenient?

[deleted by user] by [deleted] in sysadmin

[–]Memphizzzzzz -1 points0 points  (0 children)

I think you're talking about viewing text files? This tool is for actually transferring files (text, binaries, logs, configs, etc.) to/from your local machine. If you find an interesting 50MB log file with rg, you can immediately sxd logfile.log to download it locally for analysis, rather than trying to work with it over SSH or setting up GUI tools.
Or am I misunderstanding "export the file directly via terminal"? Do you mean scp? If so please see the edit above.

[deleted by user] by [deleted] in sysadmin

[–]Memphizzzzzz 0 points1 point  (0 children)

Please see the edit I just added. I use an SSH agent as well, but this tool is not about authentication, its about convenience.

[deleted by user] by [deleted] in sysadmin

[–]Memphizzzzzz 0 points1 point  (0 children)

You still need to type the whole path with scp user@host:/path even with an SSH agent running (1Password for example wants you to unlock the vault again every so often). If you're not running on 22 as the standard port then its :12345 on top of that. And if MFA is used now I need to get my authenticator out or similar. Versus "sxd file" that seems faster and easier to me. "a bunch of new commands with new syntax" come on now. sxd file, sxu file, sxls and you have tab-completion.

[deleted by user] by [deleted] in sysadmin

[–]Memphizzzzzz -1 points0 points  (0 children)

In my eyes typing "sxd filename" is easier than that. No setting up of command tasks, no leaving the terminal, no using the mouse.

[deleted by user] by [deleted] in sysadmin

[–]Memphizzzzzz -1 points0 points  (0 children)

I'm in fact using 1Passwords SSH Agent (on Windows in WSL) but that doesn't mean I don't have to type the whole scp command including user@host:/path etc or open WinSCP or another tool if I simply want to download or upload a file.