Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SSH has become our universal (Unix) external access protocol

utcc.utoronto.ca

Post reply on HN
Print view View original

91–99 of 99 posts

Re: SSH has become our universal (Unix) external access protocol

#91

Post by [deleted] »

wongarsu wrote: post #39
bluejekyll wrote: post #21

Earlier quoted context omitted.

I think the use of IDEs really made this practice less simple. Terminal mode emacs and vi/m are simple with SSH, VSCode and other things start getting more complex. I think the extensions to VSCode and others to run remotely with a browser are starting to bring some of this back into fashion.

Connecting over SSH with VSCode is the most convenient SSH experience I've ever had: VSCode runs locally, connects via SSH and makes it feel like I'm working locally. I can edit files, open terminals, run software, etc. It's like running vim, a couple terminals and a scp file manager, but with the convenience of a desktop application Technically you need an extension (Remote - SSH) but I think that's installed by def…

[deleted]

Re: SSH has become our universal (Unix) external access protocol

#92

Post by graemep »

jonhohle wrote: post #56
graemep wrote: post #40

Earlier quoted context omitted.

I find it a lot easier to manage a single Linux server than multiple AWS services and a separate third party service for every single thing. Stuff built on top of AWS like Heroku is even worse. The problem is that a lot of people are now just not comfortable running things in-house. Subscribing to another service and adding an integration feels like the safe option.

That’s not always practical for performance or availability reasons.

I am mostly thinking of circumstances where a single server would provide equal or better performance and availability than AWS.

where it would not, you can run multiple redundant servers (although that may mean more work)

Re: SSH has become our universal (Unix) external access protocol

#93

Post by jacobgkau »

whalesalad wrote: post #58
jacobgkau wrote: post #52

Earlier quoted context omitted.

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.

Re: SSH has become our universal (Unix) external access protocol

#94

Post by whalesalad »

jacobgkau wrote: post #93
whalesalad wrote: post #58

Earlier quoted context omitted.

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 reb…

> 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.

Re: SSH has become our universal (Unix) external access protocol

#95

Post by saghm »

whalesalad wrote: post #65
dspillett wrote: post #62

Earlier quoted context omitted.

> 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 opt…

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.

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).

Re: SSH has become our universal (Unix) external access protocol

#96

Post by aborsy »

politelemon wrote: post #10

An alternative I am seeing mentioned with some frequency is Tailscale, which doesn't need port 22 open to the internet, since it's using its own network's connectivity to facilitate your "tailscale SSH" connectivity. From what I read it's very similar to Amazon's SSM Agent. The usefulness here is that you're closing off ports and reducing your exposure, the downside is that you need proprietary agents installed on th…

If you enable taillock, I don’t see what a compromised coordination server could do.

Re: SSH has become our universal (Unix) external access protocol

#97

Post by dspillett »

whalesalad wrote: post #65
dspillett wrote: post #62

Earlier quoted context omitted.

> 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 opt…

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.

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

    rsync source destination
or

    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.

Re: SSH has become our universal (Unix) external access protocol

#98

Post by dspillett »

ASalazarMX wrote: post #78
whalesalad wrote: post #65

Earlier quoted context omitted.

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.

--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.

Re: SSH has become our universal (Unix) external access protocol

#99

Post by jacobgkau »

whalesalad wrote: post #94
jacobgkau wrote: post #93

Earlier quoted context omitted.

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 reb…

> 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…

> 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.

Post reply on HN