4 ms·

The main question is why use Telnet when ssh is available. Some people mentioned routers, maybe that is why. But I would think in this day and age routers wou

by jmclnx 9mo ago

The main question is why use Telnet when ssh is available. Some people mentioned routers, maybe that is why. But I would think in this day and age routers would now use ssh. I do remember reading a long time ago telnet does/can support encryption. But when I looked at the systems I have access to, the manuals have no mention of that.

drum55 9mo ago
Probably because ssh ciphers change, telnet doesn’t, and you’re not really supposed to be internet exposing those interfaces anyway.
Nextgrid 9mo ago
SSH without proper key management offers marginal benefits compared to telnet.
- gzread 9mo ago
  [dead]
- Quarrel 9mo ago
  However bad your key management is, unless you're on an older ssh that will let you choose to use the "None" cipher, you're still better off than telnet!
  - signalblur 9mo ago
    Right? It doesn’t even make sense - on any actively updated ssh agent you’d have to go out of your way. Also - SSH offers more than just encryption, but also data integrity - you can modify / manipulate a telnet session in ways you just can’t via SSH
  - trumpdong 9mo ago
    [dead]
themafia 9mo ago
Why use ssh when wireguard is available?
- 01HNNWZ0MV43FF 9mo ago
  So I don't need root permission or kernel networking stuff setup. (I do run Wireguard, it just feels like sometimes a VPN is a sledgehammer to solve a port forwarding problem)
- yjftsjthsd-h 9mo ago
  Because I want to login to my user account without sending a password over the wire. If telnet can use keypairs to authenticate users then I guess I don't mind that as a solution, but I haven't heard of it? Also I do care about per-user auth because some of us still work in environments where servers have multiple users.
  - themafia 9mo ago
    > over the wire You know what wireguard is? > If telnet can use keypairs Kerberos exists, so, yes, it can.
    - yjftsjthsd-h 9mo ago
      >> over the wire > You know what wireguard is? I suppose if you prefer, I can write "over the network". The point is that the password leaves my machine. As a practical example: With password auth, if an attacker gets root on a server then they can read your password and log in to other machines. With SSH keypairs, this isn't possible (unless you go out of your way to forward an SSH agent, and even then there are mitigations). >> If telnet can use keypairs > Kerberos exists, so, yes, it can. This sounds promising, and in fact at least one page I found about it claims that kerberos+telnet encrypts the session, at which point I don't immediately see what we need wireguard or ssh for. On the other hand, it looks like eg. GNU inetutils telnet doesn't support it? In fact, https://web.mit.edu/kerberos/krb5-1.5/krb5-1.5.4/doc/krb5-user/telnet.html https://web.mit.edu/kerberos/krb5-1.5/krb5-1.5.4/doc/krb5-us... says > The Kerberos V5 telnet command works exactly like the standard UNIX telnet program, with the following Kerberos options added: which makes it sound like they've just made a special telnet variant with these features, at which point it rather feels like we've just re-invented ssh under a different name.
shevy-java 9mo ago
I had a similar question. I use ssh usually these days. Telnet has one thing going for itself though: simplicity.
skissane 9mo ago
The biggest remaining production use of telnet is IBM mainframe and midrange systems. tn3270 which is a telnet extension implementing support for 3270 block mode terminal data streams is still in widespread use, and there is also tn5250 which does the same for 5250 terminals (used on IBM i / AS/400) This use case is perfectly secure, because IBM mainframe/midrange telnet servers support telnet-over-TLS, and that’s what people run in production For connecting to mainframes, SSH has no real advantage over TLS, and its major disadvantage is that there is no standardised way to transmit 3270/5250 data streams over it But people looking for telnet traffic over the public Internet probably won’t even notice this, because they aren’t looking for telnet over TLS - which is difficult to distinguish from whatever else over TLS - and because almost all of it goes over VPNs not the public Internet
- RupertSalt 9mo ago
  This is, as far as I know, a completely accurate and factual take. It is also nearly irrelevant. The two entities which have reported on this event are looking for tcp traffic on port 23, not TELNET protocol traffic. So indeed, as you say, if they are tunneled in VPN, or encapsulated or using an alternate port, tn3270 traffic will not be detect on port 23/tcp. Telnet over TLS is assigned to port 992, so any RFC-compliant implementation would be found there, and irrelevant, again, to the telnetd CVE reported this year. There are two facets to January's incident: the vulnerability in the GNU implementation of telnetd, and the purported, widespread blocking of port 23. The original report went out because of the coincidence they perceived there, and especially because the latter preceded the disclosure of the vulnerability! Mainframe tn3270 servers would not be subject to this vulnerability. If there had been a port filter in place, it only would've tripped-up the mainframes that still used port 23, which is evidently optional, and it says here that many admins want to keep AIX's telnetd bound to port 23 anyway. So it is good to know that TELNET protocol, and its extensions, are alive and well. We may not actually know how many clients and servers implement the protocol itself, since MUDs made this a routine thing, but certainly the deployment of IBM systems is formidable, considering the sheer mass of the iron in their rack mounts.
harrall 9mo ago
You can wrap any TCP protocol in TLS which means every TCP protocol supports encryption, Telnet included. The app (and server) simply need to wrap their connections in TLS, which is trivial in many programming ecosystems. And IMO, X.509 (used in TLS) is virtually superior over SSH’s bespoke certificate format in every way. You get both regular certificate pinning (like what SSH uses now) AND full certificate authority chains (if you want). The main downside is that X.509 is more complex.
- yjftsjthsd-h 9mo ago
  > You get both regular certificate pinning (like what SSH uses now) AND full certificate authority chains (if you want). It doesn't do full chains, but SSH does have certificate authorities. I agree that the lack of intermediate CAs is a limitation (a CA can only sign a leaf node public key directly), but it's still super useful.
benjojo12 9mo ago
It is surprisingly common to find routers with " export firmware " installed out of the box, that do not have ssh support to avoid the interactions with US Cryptographic export licencing complications

by jmclnx 9mo ago

drum55 9mo ago

Probably because ssh ciphers change, telnet doesn’t, and you’re not really supposed to be internet exposing those interfaces anyway.

Nextgrid 9mo ago

SSH without proper key management offers marginal benefits compared to telnet.

gzread 9mo ago
[dead]
Quarrel 9mo ago
However bad your key management is, unless you're on an older ssh that will let you choose to use the "None" cipher, you're still better off than telnet!
- signalblur 9mo ago
  Right? It doesn’t even make sense - on any actively updated ssh agent you’d have to go out of your way. Also - SSH offers more than just encryption, but also data integrity - you can modify / manipulate a telnet session in ways you just can’t via SSH
- trumpdong 9mo ago
  [dead]

themafia 9mo ago

Why use ssh when wireguard is available?

01HNNWZ0MV43FF 9mo ago
So I don't need root permission or kernel networking stuff setup. (I do run Wireguard, it just feels like sometimes a VPN is a sledgehammer to solve a port forwarding problem)
yjftsjthsd-h 9mo ago
Because I want to login to my user account without sending a password over the wire. If telnet can use keypairs to authenticate users then I guess I don't mind that as a solution, but I haven't heard of it? Also I do care about per-user auth because some of us still work in environments where servers have multiple users.
- themafia 9mo ago
  > over the wire You know what wireguard is? > If telnet can use keypairs Kerberos exists, so, yes, it can.
  - yjftsjthsd-h 9mo ago
    >> over the wire > You know what wireguard is? I suppose if you prefer, I can write "over the network". The point is that the password leaves my machine. As a practical example: With password auth, if an attacker gets root on a server then they can read your password and log in to other machines. With SSH keypairs, this isn't possible (unless you go out of your way to forward an SSH agent, and even then there are mitigations). >> If telnet can use keypairs > Kerberos exists, so, yes, it can. This sounds promising, and in fact at least one page I found about it claims that kerberos+telnet encrypts the session, at which point I don't immediately see what we need wireguard or ssh for. On the other hand, it looks like eg. GNU inetutils telnet doesn't support it? In fact, https://web.mit.edu/kerberos/krb5-1.5/krb5-1.5.4/doc/krb5-user/telnet.html https://web.mit.edu/kerberos/krb5-1.5/krb5-1.5.4/doc/krb5-us... says > The Kerberos V5 telnet command works exactly like the standard UNIX telnet program, with the following Kerberos options added: which makes it sound like they've just made a special telnet variant with these features, at which point it rather feels like we've just re-invented ssh under a different name.

shevy-java 9mo ago

I had a similar question. I use ssh usually these days. Telnet has one thing going for itself though: simplicity.

skissane 9mo ago

The biggest remaining production use of telnet is IBM mainframe and midrange systems. tn3270 which is a telnet extension implementing support for 3270 block mode terminal data streams is still in widespread use, and there is also tn5250 which does the same for 5250 terminals (used on IBM i / AS/400) This use case is perfectly secure, because IBM mainframe/midrange telnet servers support telnet-over-TLS, and that’s what people run in production For connecting to mainframes, SSH has no real advantage over TLS, and its major disadvantage is that there is no standardised way to transmit 3270/5250 data streams over it But people looking for telnet traffic over the public Internet probably won’t even notice this, because they aren’t looking for telnet over TLS - which is difficult to distinguish from whatever else over TLS - and because almost all of it goes over VPNs not the public Internet

RupertSalt 9mo ago
This is, as far as I know, a completely accurate and factual take. It is also nearly irrelevant. The two entities which have reported on this event are looking for tcp traffic on port 23, not TELNET protocol traffic. So indeed, as you say, if they are tunneled in VPN, or encapsulated or using an alternate port, tn3270 traffic will not be detect on port 23/tcp. Telnet over TLS is assigned to port 992, so any RFC-compliant implementation would be found there, and irrelevant, again, to the telnetd CVE reported this year. There are two facets to January's incident: the vulnerability in the GNU implementation of telnetd, and the purported, widespread blocking of port 23. The original report went out because of the coincidence they perceived there, and especially because the latter preceded the disclosure of the vulnerability! Mainframe tn3270 servers would not be subject to this vulnerability. If there had been a port filter in place, it only would've tripped-up the mainframes that still used port 23, which is evidently optional, and it says here that many admins want to keep AIX's telnetd bound to port 23 anyway. So it is good to know that TELNET protocol, and its extensions, are alive and well. We may not actually know how many clients and servers implement the protocol itself, since MUDs made this a routine thing, but certainly the deployment of IBM systems is formidable, considering the sheer mass of the iron in their rack mounts.

harrall 9mo ago

You can wrap any TCP protocol in TLS which means every TCP protocol supports encryption, Telnet included. The app (and server) simply need to wrap their connections in TLS, which is trivial in many programming ecosystems. And IMO, X.509 (used in TLS) is virtually superior over SSH’s bespoke certificate format in every way. You get both regular certificate pinning (like what SSH uses now) AND full certificate authority chains (if you want). The main downside is that X.509 is more complex.

yjftsjthsd-h 9mo ago
> You get both regular certificate pinning (like what SSH uses now) AND full certificate authority chains (if you want). It doesn't do full chains, but SSH does have certificate authorities. I agree that the lack of intermediate CAs is a limitation (a CA can only sign a leaf node public key directly), but it's still super useful.

benjojo12 9mo ago

It is surprisingly common to find routers with " export firmware " installed out of the box, that do not have ssh support to avoid the interactions with US Cryptographic export licencing complications