So when you ssh into something it doesn't send silly stings like "username:" or "password:" . That stuff is handed "in protocol" . David On Sun, Mar 27, 2016, 2:17 PM D. Hugh Redelmeier <hugh@mimosa.com> wrote:
| From: Alvin Starr <alvin@netvel.net>
| On 03/27/2016 10:02 AM, James Knott wrote:
| I do not know for sure but It was my understanding that if you know the | payload it is possible to back calculate the encryption keys and | invariably switches sent a standard banner and a Username: Password:. | There may be better security with key based login and no password. | On the other hand I am sure the encryption is good enough to stop all | but nation states or folks like SPECTRE or KAOS.
When you are trying to break a cryptosystem, you have a leg up if you know the plain text. That does not mean that you can break the system. So good crypto hygiene, often at the protocol level, reduces known plain text.
For example, if your key is based only on a password, then trying all passwords might be feasible. Know plain text lets you easily check whether a particular guess is correct.
SSH public/private keypairs are as long as you want. They are not passwords. Usually 2k or more bits of RSA these days. That's too large to brute force, probably until quantum computers work better. But one never knows. Do make sure your keys are long enough.
So no, I don't think that the known plain text exposed by SSH is a problem. But I'm not a cryptographer.
| | >> A lot of the lower end switches use a http web interface which is no | >> more secure than telnet. | > Many use https, instead of plain http. Again, it's the same key | > situation as with ssh.
HTTPS, as it is used, is a bit more risky than ssh. First of all, lots of obsolete versions of TLS and SSL had security bugs at the protocol and implementation levels. And those versions are frozen into much firmware.
Secondly, authentication, as used, is substandard. I'm talking about within-protocol authentication -- passwords are not part of TLS/SSL. Without authentication, a man-in-the-middle attack is trivial. The normal form of authentication for SSL/TLS is x.509 certificates. Unfortunately, the client end is almost never authenticated. In the case of switches, the normal procedure is for the switch (the server) to use self-signed certificates in a way that provides no actual authentication.
| On 03/27/2016 10:02 AM, James Knott wrote:
| > As I mentioned earlier, in order to attack a password, you have to see | > the data. That doesn't happen much with switches, though it was quite | > easy prior to switches. Also, remote management is generally done via | > vlan, which makes it a bit more difficult for a casual eavesdropper.
A switch offers fewer easy points of interception but they are available anywhere along the path unless it is within your security perimeter. I can imagine that switches could get attacked via spoofed packets too.
| I have to lots of switch management remotely. | I do login to the local networks via VPN but you never know what is in | the middle on the internet or even the local network.
A good VPN, well-deployed, should be safe. Depending on your threat model.
================
I talk to my routers (gateways actually) through SSH. I can talk to them through IPSec too. But that's because they are PCs running ordinary Linux.
My gateways' SSH servers don't allow password authentication. They are constantly hit by SSH attempts from miscreants, all password based. --- Talk Mailing List talk@gtalug.org https://gtalug.org/mailman/listinfo/talk