[Yeah, I know, we've wandered off topic. But security is fun to talk about.] On 7/31/2001 at 12:41:23 -0400, alex@yuriev.com said:
2) Your vendor's ssh authentication creates a secure connection, and transfers the password securely, only to then send the password, unencrypted, to an authentication server for verification, making ssh moot.
Establish reasonable path for trust propagation and you have solved the problem.
Except, of course, if I had a reasonable path for trust propigation, I would have a trusted path for telnet logins. ;-) Any compromise on a clear-text telnet password is going to be viable against any other clear-text password transmission. Even restricting logins to certain host ranges only pushes security to those networks. If you're going to sniff my backbone passwords, the networks that are wrapped in are presumably compromised already. Network security is a beast. There's no sure method. Of course, the compromises get progressively more unlikely as time goes on (including keyboard sniffing and signal analysis.) So the question becomes, what is secure enough? If you're only using telnet, with clear passwords, restricted to a certain range (which, by the way, despite a recent post to nanog, we are doing; I'd like to say we left that router open so folks could read my poetry, but the truth is, we were morons and missed it) you're secure as long as your backbone links and backend aren't being sniffed. Physically tapping fiber isn't terribly easy for the average hacker, and careful routing protocol selection and implementation should keep you from external intrusion. So really, your back-end that's the most likely way in. So... does anybody know how long it takes to hack an ssh key given identity and identity.pub? Because, if I have your machine, I have these... it's just a matter of unlocking your passphrase. (And not even that, if you're running ssh-agent and I can get to that...) -- Dave Israel Senior Manager, IP Backbone Intermedia Business Internet