5 ms·

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

by chasil 3y ago

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

pmontra 3y ago
Is this the CVE that makes scp insecure? https://bugzilla.redhat.com/show_bug.cgi?id=1860487 https://bugzilla.redhat.com/show_bug.cgi?id=1860487
- arp242 3y ago
  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).
riffic 3y ago
zero trust begs to differ. practicing defense in depth is almost always a better approach.
- slondr 3y ago
  For corporate environments sure, for my home lab that seems like overkill
  - jcrawfordor 3y ago
    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.
  - riffic 3y ago
    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.
    - genewitch 3y ago
      The compromised device is inside the house!
mobilio 3y ago
OR when this is in home LAN without forwarded ports
mixmastamyk 3y ago
Not a good idea for cleartext even on a network you trust. Maybe one node, but why start bad habits?
- chasil 3y ago
  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.
  - kortilla 3y ago
    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.
fragmede 3y ago
Wait, why is scp deprecated?
- chasil 3y ago
  The server can do bad things to you. https://lwn.net/Articles/835962/ 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.
  - quickthrower2 3y ago
    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?
    - chasil 3y ago
      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."
  - hddqsb 3y ago
    In fact OpenSSH has already done so! https://www.openssh.com/txt/release-9.0 https://www.openssh.com/txt/release-9.0
- arp242 3y ago
  Only the protocol; the /bin/scp tool uses the sftp protocol by default now. You can just continue using it without fear.
kstrauser 3y ago
SSH auth is way more convenient than telnet’s username/password. That alone’s enough for me to prefer SSH to telnet.
wkat4242 3y ago
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
- TedDoesntTalk 3y ago
  > 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.
  - dgl 3y ago
    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 https://en.wikipedia.org/wiki/10BASE2
    - shagie 3y ago
      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.
tedunangst 3y ago
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.
- chasil 3y ago
  I am hoping that "yum install telnetd" is going to give me something safe. For our VAX? Oh boy...
  - wyldfire 3y ago
    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.
tptacek 3y ago
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.
- codetrotter 3y ago
  > 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.
- chasil 3y ago
  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 https://gunkies.org/wiki/Installing_VMS_V1.0_on_SIMH (Yes, I have set this up.)
hddqsb 3y ago
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.)

by chasil 3y ago

pmontra 3y ago

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

arp242 3y ago
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).

riffic 3y ago

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

slondr 3y ago
For corporate environments sure, for my home lab that seems like overkill
- jcrawfordor 3y ago
  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.
- riffic 3y ago
  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.
  - genewitch 3y ago
    The compromised device is inside the house!

mobilio 3y ago

OR when this is in home LAN without forwarded ports

mixmastamyk 3y ago

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

chasil 3y ago
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.
- kortilla 3y ago
  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.

fragmede 3y ago

Wait, why is scp deprecated?

chasil 3y ago
The server can do bad things to you. https://lwn.net/Articles/835962/ 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.
- quickthrower2 3y ago
  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?
  - chasil 3y ago
    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."
- hddqsb 3y ago
  In fact OpenSSH has already done so! https://www.openssh.com/txt/release-9.0 https://www.openssh.com/txt/release-9.0
arp242 3y ago
Only the protocol; the /bin/scp tool uses the sftp protocol by default now. You can just continue using it without fear.

kstrauser 3y ago

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

wkat4242 3y ago

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

TedDoesntTalk 3y ago
> 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.
- dgl 3y ago
  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 https://en.wikipedia.org/wiki/10BASE2
  - shagie 3y ago
    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.

tedunangst 3y ago

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.

chasil 3y ago
I am hoping that "yum install telnetd" is going to give me something safe. For our VAX? Oh boy...
- wyldfire 3y ago
  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.

tptacek 3y ago

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.

codetrotter 3y ago
> 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.
chasil 3y ago
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 https://gunkies.org/wiki/Installing_VMS_V1.0_on_SIMH (Yes, I have set this up.)

hddqsb 3y ago

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