Hacker News Reader

Comment by chasil | Hacker News Reader

> "For the purposes of logging into a remote server, you should never, and probably have never considered it."

This is not true when the client and server have both implemented Wireguard.

With Wireguard in place, it is safe to return to legacy telnet, ftp, and rsh. The use of rcp still remains problematic, for the same reasons that scp is deprecated.

It is not best practice to return and rely on these legacy protocols, as they are bad habits and are vulnerable when Wireguard (or equivalent protections at a lower level in the network stack) are in place.

View on HN

No, it isn't, because a secure channel isn't the only thing SSH does to secure remote access. Consider that large fleet operators tend to use certificate authentication with SSH, and then work out how to replace that cleanly with telnet or rsh.

There is something to the idea of drafting off of WireGuard's security! We have a WireGuard mesh internally, and I would push back on deploying something like mTLS on top of it. But we still need something like SSH to manage (not just encrypt, but manage) access.

> We have a WireGuard mesh internally

I’ve got one too, and I ssh over Wireguard to various machines in the mesh. But I’ve been thinking recently that one big shared Wireguard internal VPN that lets every machine get access to all ports of one-another is really not ideal.

And in light of that; if my Wireguard setup was more strict, then perhaps I would not even need ssh. But on the other hand I would prefer to keep my defences deep. I sleep better knowing that even if I mess up something with the Wireguard setup and the listening ports and addresses for host logins at least everything still has ssh protecting it.

Anybody thinking about telnet logins is not going to have the slightest thought of using a certificate authority for authentication.

If you think otherwise, I will invite you to implement this for SimH:

https://gunkies.org/wiki/Installing_VMS_V1.0_on_SIMH

(Yes, I have set this up.)

Well I used telnet before ssh was even a thing. It wasn't that weird back then and most internet systems were multi user where the common man didn't have root permissions. Thus so sniffing rights.

In those days we also still used 10base2 so there wasn't even a switch involved. Every system could see each other's traffic. X terminals didn't have xauth in the beginning so anyone could connect to your terminal and screen grab or pop up pictures (something I did regularly for practical jokes)

On the one hand it's kinda crazy not many bad things happened back then. On the other, not too much important stuff was online in those days. And only a handful knew how it worked.

But yeah telnet and rlogin (authentication simply by having the right IP!!) were the tool for the job for many years believe it or not.

/GrandpaMode

> In those days we also still used 10base2 so there wasn't even a switch involved

You’re thinking of a hub (repeats all packets on all ports).

This is how I recorded Vonage VoIP calls 20 years ago from anyone using the same hub in the residence.

10baseT would imply a hub, but 10base2 is “thinnet” (because the cable was thinner than the previous standard) where a coax cable runs between all devices on the segment, with no central device connecting them together.

https://en.wikipedia.org/wiki/10BASE2

Incidentally, it was the same signal that ran on 10base5 with the vampire taps.

At the lab I hung out in as an undergrad, someone found what was termed "the connector of evil." On one end it looked like a thinnet terminator and on the other it looked to be a thicknet terminator - but they didn't terminate, it was a pass through.

And we used it. Some of the machines had 10b5 connectors and some had 10b2. The ones that used 10bT were at the other end of the room where the hub was.

The fun part was tracking down the inevitable "that machine dropped off the net" because the standing wave wasn't quite right for the thicknet side (and made the thinnet side unhappy too).

So we set it up to do a ping -f of an IP on the subnet that was on the 10bT side and redirect it to /dev/audio. This way machines that were on the net had speakers that were chipping away while those that had fallen off were silent. And then we'd go about swapping lengths of coax to get the standing wave to establish again when everything was chirping away... until we had to add another machine.

in the mid-90s i was invited to fix several schools' networks, a couple were novell and i forget what the others were (edit: also appletalk, which was similar but used 2 pairs on "telephone jacks", including little phone jack resistors), and those BNC connectors (or were they TNC?) were connected to stiff wires so any movement of the very heavy PCs connected to them tended to shear solder joints. I even had to replace "thinnet" coax that rats had eaten through.

I bet if i open my parts cabinet i still have enough stuff to build a token ring 10base2 network right now.

There existed 10Base2 hubs (repeaters), because there were still limitations on cable length and the need to isolate bad segments.

No. Not a hub. That was 10baseT.

10base2 was a coaxial cable (RG-58) shared by all devices. Each would have a T-splitter and there would be a terminator plug at the end. Removing that would cause half the network to stop working. Before that there was also another standard with ticker cable (RG-213) called 10Base5 but that was before my time. 10Base2 was still the way the network worked everywhere in my college though.

It was expensive and messy. Technically it worked a bit like a hub but it was a very different topology. At least physically (electrically it wasn't too different from how a hub shares its signals)

The hub was built to emulate the behavior of 10base2 and 10base5.

10base5 was the original inch-thick coax, and adaptors actually drilled into the cable. I have found 10base5 taps in odd places over the decades of my career.

10base2 was coax cable that we recognize, and there were t-connectors that allowed two cables to link into a host's network adapter.

The ends of the cable were capped with resistors ("terminators") that would radiate network traffic into (a very small amount of) heat.

This model uses CSMA/CD (carrier sense mutiple access/collision detect) very literally. Any station could transmit at any time, up to a maximum of 1518 bytes, including the Ethernet frame header. Transmit collisions were detected as frame size overruns. If the cable were too long, the ends would see correct transmissions, but the middle would see collisions. This explains the 500 and 200 meter limits of 10base5 and 10base2.

An understanding of this original topology and its limits is informative in the reasoning for modern Ethernet.

And thanks to this subthread, I am getting flashbacks of crimping things onto coaxial cable.

Well ... perhaps augmented by the fact that I was using a crimping tool yesterday. But that wasn't coaxial cable. (-:

The advice "never use telnet" is fine. Yes, technically there are ways to use telnet safely (e.g. over WireGuard or a LAN), but they are fragile and I think it's better not to mention them.

Take the version in your comment for example. You wrote "With Wireguard in place, it is safe to return to legacy telnet", but that on its own is misleading: it is easy to accidentally route the connection outside WireGuard and compromise the password.

You do note later that it's not best practice and can be vulnerable (aside: I assume "are in place" should be "are not in place"), but a reader might miss that part or underestimate the risk.

Also, "safe" is subjective: telnet allows all the users on the network to try to bruteforce passwords. (SSH also allows that by default, but not for the root account, and it lets you disable password authentication entirely in favour of public key authentication etc.)

I think it's fine to give broadly-applicable-but-technically-inaccurate advice ("never use telnet"), and trust that the experts who can safely ignore this advice will understand that the advice is a simplification. (To be hyper-correct, one should give the broadly-applicable advice but also state that there are exceptions.)

SSH auth is way more convenient than telnet’s username/password. That alone’s enough for me to prefer SSH to telnet.

zero trust begs to differ. practicing defense in depth is almost always a better approach.

For corporate environments sure, for my home lab that seems like overkill

SSH is not overkill, it is the default. There are some narrow circumstances where you might have a good reason to use telnet in 2023, but they are edge cases related to legacy hardware and possibly occasionally the desire for easy on-path interception. It is very unlikely that you have a good reason to not just use SSH. Even if you care nothing about the security advantages, SSH has more consistent and better-defined behavior around 8-bit data, and offers far more features.

first of all, I do not see your home "lab" and anyone else's home LAN to be synonymous as a concept.

Franky, do what you want in your lab.

I would urge you or anyone else to assume there's already a compromised device on your home network.

The compromised device is inside the house!

There have been a variety of vulnerabilities in telnetd as well, so you should think twice if you don't have absolute trust in your users.

I am hoping that "yum install telnetd" is going to give me something safe.

For our VAX? Oh boy...

telnetd probably doesn't have too many eyeballs, so I wouldn't be too confident about it really. Whatever eyeballs are focused on telnetd are less likely to be ones who take security as a major concern.

Is this the CVE that makes scp insecure? https://bugzilla.redhat.com/show_bug.cgi?id=1860487

Yes, but note this is only the scp protocol. The /bin/scp tool uses the sftp protocol by default now, and you can just continue using it without problems (if you ssh is new enough; check the manpage).

OR when this is in home LAN without forwarded ports

Wait, why is scp deprecated?

The server can do bad things to you.

https://lwn.net/Articles/835962/

The author of PuTTY quietly set pscp to prefer the SFTP protocol for these reasons; OpenSSH stated their intention to do the same.

I don't understand that article. Those issues look easy to patch up? The first one has been. The second one seem like a case of not allowing the server to execute text sent by the client in the filename?

The original scp used rcp (as a protocol, or very close to it) inside of ssh.

IIRC, wildcards are allowed, so the rcp server expands them.

If the rcp server is malicious, it might slip an /etc/passed into its output, writing over the client. Very bad if the client is root.

The original scp suffers the same problem. I'm not sure if this issue is entirely avoided if a fully-qualifed path is sent to the server (but I think so).

EDIT: I am incorrect. The rcp server has complete control over the filename sent.

"...So one might type a command like:

  $ scp admin:boring-spreadsheet.ods .

"with the expectation of getting a file called boring-spreadsheet.ods in the current working directory. If the remote server were to give a response like "here is the .bashrc file you asked for", though, scp would happily overwrite that file instead."

In fact OpenSSH has already done so! https://www.openssh.com/txt/release-9.0

Only the protocol; the /bin/scp tool uses the sftp protocol by default now. You can just continue using it without fear.

Not a good idea for cleartext even on a network you trust. Maybe one node, but why start bad habits?

Wireguard will encapsulate all your traffic inside UDP packets encrypted with chacha20-poly1305.

Networking between two Wireguard hosts will never see TCP on the wire.

Bad habits are OK with this in place.

No they aren’t, because there can be multiple users on the same host that can do something else that briefly changes the routing table and suddenly your destination that would go over wireguard goes over something else.

Ssh gives you process to process security, which is far far better than host to host.

Reply on news.ycombinator.com