Comment by themafia
10 days ago
> over the wire
You know what wireguard is?
> If telnet can use keypairs
Kerberos exists, so, yes, it can.
10 days ago
> over the wire
You know what wireguard is?
> If telnet can use keypairs
Kerberos exists, so, yes, it can.
>> 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-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.
> With SSH keypairs
Which is just an abstraction of a password. Instead of storing it in your mind and sending it over the network you store it on your harddrive and use to calculate things on the network. Haven't you just moved the security boundary slightly? You're now also mixing up authentication and encryption into one package which isn't strictly an upside. Granted you can secure your key with a password or a yubikey but now you're messing with agents or you're typing that password an incredible amount.
I see your point. The dead simplicity of telnet session over encrypted tunnel still appeals to me in the face of the structures above. It also means you can elide the whole "how do I do this complicated port forwarding with ssh" question entirely.
> we've just re-invented ssh under a different name.
ssh is the best implementation of self signed security you can get. With kerberos we actually get a central authority and it separates authentication and encryption rather nicely without requiring user agents running as daemons.
> Which is just an abstraction of a password.
I don't think that's functionally true. The important thing is that with telnet or password-auth ssh, you send the actual text of your password to the server. With ssh keys, the server and client do some magic crypto math to let you prove you control the private key without ever sending it. Therefore, a compromised server can steal a password, but not a ssh key.
(Yes, in theory perhaps you could do some fancier way of proving that you know a password without sending it, but 1. I'm no cryptographer, but the fact that openssh hasn't done this feels suggestive, and 2. that is once again a pretty big change for the nominal goal of keeping telnet)
> ssh is the best implementation of self signed security you can get. With kerberos we actually get a central authority and it separates authentication and encryption rather nicely without requiring user agents running as daemons.
Sure. Like, I've never thoroughly evaluated kerberos in depth (again, I'm no cryptographer), but I hear generally good things. My point is that by the time you have kerberos, you aren't really using what I would call telnet anymore, you're using something that acts like telnet but backs into a completely different authentication and communication system, and at that point you might as well use a completely different authentication and communication system without pretending to be telnet. This goes double because (open)ssh does support kerberos.