Hacker News Reader

Comment by whalesalad | Hacker News Reader

Need to get a file from one box to another? Have SSH? `scp` is your friend: https://en.wikipedia.org/wiki/SSH_File_Transfer_Protocol

    scp remote.host:path.txt local
    scp local remote.host:path

Need a fast proxy to browse the internet securely and bypass restrictions without a VPN? SSH SOCKS proxy! Supported by most operating systems, but I tend to use it directly via Firefox so that it is isolated to one browser. This starts a socks proxy on the desired port:

    ssh -D $port $host

Firefox has network settings, simply choose SOCKS, 127.0.0.1 as the IP and the specified port as the port. Then you're off to the races.

Until we had proper VPN infrastructure to enter our VPC at AWS I would utilize this to view private vpc-only RMQ dashboards.

Love SSH!

View on HN

If you use container tabs in Firefox, you can also configure proxies on a per-container basis! In case that’s useful to other people besides me.

In case anyone besides me had never heard of this feature:

https://support.mozilla.org/en-US/kb/how-use-firefox-contain...

Wow, how come this is not a default feature.

> Need to get a file from one box to another? Have SSH? `scp` is your friend

For less trivial transfers (recursive structures, large collections that you want to sync with minimal time) rsync supports SSH as a transport medium out of the box so

    scp remote.host:path.txt local
    scp local remote.host:path

becomes

    rsync remote.host:path.txt local
    rsync local remote.host:path

for the basics, then start adding the other options that you need:

    rsync some/local/dir me@remote.host:/target/ --recursive --times
    rsync some/local/dir me@remote.host:/target/ --archive # archive does recursive and also preserves times, ownership, etc.
    rsync some/local/dir me@remote.host:/target/ --recursive --delete-before --dry-run
    … … …

In fact, I usually end up using rsync even for the basics, just out of habit typing that instead of scp.

I must admit my rsync experience is limited. I do not know the behaviors and flags very deeply. It's on my list though, as it's surely another one of those foundational linux tools. I know it is even faster than cp on the same host for some situations.

rsync is the tar of network transfers. It is extremely useful, but has too many options, so one ends up memorizing a few use cases and carefully sticking to them.

I still have PTSD from the time I played with the options and made the mistake of swapping source and destination, where the destination was a blank disk.

haha, you say rsync is the tar of network transfers, but have you ever considered using tar for network transfers?

Time a 'tar | nc' sometime to a remove server, it'll blow away the rsync time.

you are not wrong, but you are missing the argument

--dry-run is a useful safety net when trying new combinations of options. That, and the fact it'll never delete unless you specifically give it an option with "delete" in its name.

In my experience, rsync is a tool that's worth it despite not knowing most of what it can do. I use `-a` to get the behavior you want (which is superset of a bunch of options like preserving filesystem permissions, copying recursively, and other things I haven't bothered to memorize) `--info=progress3` to show progress/network speed updating on a single line (no idea what the other progress options do, but this one does what I want), and if I'm transferring something that's not already compressed, I use `-z --compress-choice=zstd`. After those flags, it's basically a drop-in replacement for scp (`remote:srcpath dstpath` for copying to local and `srcpath remote:dstpath` for copying to remote).

The basics for just copying files as you would with scp are pretty intuitive:

    rsync source destination

    rsync source destination --recursive

with the only extra gotcha being that you need to be careful whether you need trailing /s on directories (sometimes where CP or scp would complain and exit, rsync will do something that isn't quite what you intended).

The first complication you might hit is when you want to sync, including deleting files at the destination as needed, rather than just copying. This isn't _that_ complicated really, but caution is understandable because mistakes can cause unintended deletions. The --dry-run and verbose output options are your friend here, and the assurance that it won't delete anything unless you explicitly give it one if the --delete* options.

SCP (what you showed as an example) and SFTP (what you linked to a Wikipedia page for) are not the same thing. SCP is an older protocol and, while faster in some situations, is essentially abandoned. Newer versions of OpenSSH actually use SFTP even if you use the SCP command, so you might as well just use the SFTP command instead.

the cli command is called scp but is using sftp under the hood. tomato tomato.

No, that is not correct. The SCP command was historically for a separate protocol, Secure Copy Protocol (and prior to 2022, it actually used that protocol). SFTP is Secure File Transfer Protocol. They are two separate things, and conflating them because of a compatibility layer is simply wrong.

It's like saying the classic reboot utility and systemd are the same thing just because modern Linux distros symlink the reboot command to systemctl. Or, to stretch a little further, like saying HTTP and HTTPS are the same thing just because most websites redirect one to the other.

There's no justification for spreading confusion and relying on a compatibility behavior for an obsolete command. That compatibility behavior is not present on pre-2022 distros, and may be removed again in the future once people are expected to have updated their scripts & whatnot. You're evangelizing SFTP, just use the SFTP command.

> classic reboot utility and systemd are the same thing just because modern Linux distros symlink the reboot command to systemctl

You are acknowledging my point - in this case they ARE the same thing. If it looks like a duck, quacks like a duck, and walks like a duck - it's a duck. This is like arguing symlinks are wrong and instead of `python` you must use `python3.12` even though they are ultimately identical. Read the man page for `scp` and read the man page for `sftp` and seriously tell me why I should use one over the other.

> That compatibility behavior is not present on pre-2022 distros

Who is using a pre-2022 distro reading this comment? And I have been using scp (with SSH, SFTP) for a lot longer than since 2022. Like over a decade.

Your comment reads like an HOA enforcer. Just raising fuss for no actual benefit.

> You are acknowledging my point - in this case they ARE the same thing. If it looks like a duck, quacks like a duck, and walks like a duck - it's a duck.

Ok, so two programs with different code that perform the same task are identical to you. There are never any merits or drawbacks on implementation according to you.

All the extra features that SFTP has but SCP doesn't don't exist, because "looks like a duck, quacks like a duck." SCP being faster but not allowing resuming interrupted transfers doesn't matter, because "looks like a duck, quacks like a duck."

If this is the level of thought you put into your tech, you don't seem worth arguing with, but you also don't seem like someone who should be "teaching" anything to anyone in your own comments.

> Who is using a pre-2022 distro reading this comment?

Plenty of enterprises. That's only two years ago. People still use systems far older than that.

This does include Ubuntu 22.04 LTS, which shipped OpenSSH 8.9. It would also include RHEL 9, which shipped OpenSSH 8.7, if Red Hat hadn't specifically patched it with the updated behavior.

Here's Red Hat talking about SCP being deprecated in RHEL 9, specifically: https://www.redhat.com/en/blog/openssh-scp-deprecation-rhel-... Interesting how much they have to say about the topic since there's apparently no difference, according to you.

> And I have been using scp (with SSH, SFTP) for a lot longer than since 2022. Like over a decade.

You probably weren't, you were probably using SCP. Optional SFTP support wasn't even added to the SCP command until 2020, committed in 2021, so "over a decade" is just factually impossible: https://github.com/openssh/openssh-portable/commit/197e29f1c...

This is why you need to know these things, because now you kind of look like an idiot for not even knowing the tools you use.

My company's VPN had some weird quirks with routing and DNS that were preventing me getting to certain web frontends, and being able to do a quick SOCKS proxy to get my Firefox accessing the corp network as if it was doing so from a machine in the office was a lifesaver.

sshuttle[0] is a great tool that turns a regular SSH connection into something that behaves more like a traditional VPN.

e.g. I can run "sshuttle -r myserver example.com", and when I next load example.com in my web browser (without any special configuration) it'll be routed via `myserver`.

[0] https://github.com/sshuttle/sshuttle

I don't see how this gets around a VPN? I still need a host in your example. That's what I'm paying a VPN for, a bunch of hosts around the world that are relatively fast.

It doesn't "get around" a VPN. It's an alternative available to you if you have SSH access to a remote host with its own internet connection.

I used a server running in AWS for this while in China. Sometimes you don’t have a VPN, or using certain VPN providers might be heavily monitored and/or blocked.

My roommate was visiting family in China a few years back and I did the same thing. Got him sorted with SSH access to one of our servers and he was able to SOCKS proxy to bypass all of their unhinged filtering.

Had a family member stationed overseas with the military. Bank of America chose to geo-lock IP access to their customer website. Used SSH box in the USA and informed them on how to configure their laptop to get around the restriction. No need to pay for a VPN or configure one for a single use. Ironically Bank of America had a local branch at the overseas military base.

SSH is the best network service multi-tool. From remote shell, to file transfer, to network routing.

VPN != VPN. You're thinking about "paid proxy for e.g. piracy", they're thinking of "tool to make computers in two different locations believe they're on the same LAN". Both are the same technology under the hood, but the use differs.

In this case you've got a network with some devices on it in location A, and a device in location B and you'd like to make B believe it's on the LAN of location A. Both a traditional VPN such as wireguard or OpenVPN and SSH with SOCKS can accomplish this.

Reply on news.ycombinator.com