RE: telnet vs ssh on Core equipment , looking for reasons why ?
Sadly, there are two good reasons to use telnet to connect to core equipment, even in this day and age: 1) You have legacy equipment that does not support ssh, and/or your vendor does not include ssh in every release of code (specifically, code you need to run.) 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. -Dave On 7/31/2001 at 11:54:38 -0400, Daniel Golding said:
I believe that folks are having problems saying why they use SSH instead of telnet, because the best practice is simply so self-evident.
SSH gives you a measure of protection against bad people sniffing out your passwords. Telnet does not. SSH is encrypted. Telnet is not. It's pretty easy - only use telnet if you must. Use SSH if you possible can. Of course, this also holds true for using scp instead of ftp, although scp isn't as widely supported, yet.
- Daniel Golding
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Mr. James W. Laferriere Sent: Tuesday, July 31, 2001 11:25 AM To: nanog@merit.edu Subject: Re: telnet vs ssh on Core equipment , looking for reasons why ?
Hello All , Thank you for the disertations & insight into the possible methods of compromising an authentication attempt .
But , I am really interested more in 'Why' each responsible indidvual(s) chose either telnet or ssh to manager their Core equipment .
ssh 1 ) Has been the encrypted authentication .
telnet 1 ) Has been legacy OS's / Equipment olny supporting telnet .
On Tue, 31 Jul 2001, Mr. James W. Laferriere wrote:
Hello All , I have charged myself with trying to find a statistic on how many individuals responsible for IP core equipment recommend telnet or ssh & why particularly . I will summarize .
Tia , JimL
+------------------------------------------------------------------+ | James W. Laferriere | System Techniques | Give me VMS | | Network Engineer | P.O. Box 854 | Give me Linux | | babydr@baby-dragons.com | Coudersport PA 16915 | only on AXP |
+------------------------------------------------------------------+
-- Dave Israel Senior Manager, IP Backbone Intermedia Business Internet
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. Alex
1) You have legacy equipment that does not support ssh, and/or your vendor does not include ssh in every release of code (specifically, code you need to run.) You can normally work around this - worst case, run a null-modem between
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. Bad design - but again, you can usually work around it. VPN tunnel (or SSH
that box and the closest box that *does* support SSH, allow normal console logins on that port.... port forwarding) to the auth server springs to mind (if supported) or a dedicated OOB mininetwork in the 1918 range just for the authentications. even legacy 10base2 would be ok for that - it is not as if speed matters for it. Or just use local logins for each one - I know it is much cleaner for admin purposes to have a central auth server (add username once, in one place) but a push-out solution *can* be made to work...
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.
Less moot if a) The p/w contains one-time p/w components, or (if you like logging into your routers more often) b) You configure aaa to run over ip-sec (say), and fall back to console access which is either out of band, or contains one time passwords -- Alex Bligh Personal Capacity
On Tue, 31 Jul 2001, Dave Israel wrote:
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.
Use local AAA users. Of course, this doesn't scale well if you have 200 routers. --Ariel --Ariel
-Dave
On 7/31/2001 at 11:54:38 -0400, Daniel Golding said:
I believe that folks are having problems saying why they use SSH instead of telnet, because the best practice is simply so self-evident.
SSH gives you a measure of protection against bad people sniffing out your passwords. Telnet does not. SSH is encrypted. Telnet is not. It's pretty easy - only use telnet if you must. Use SSH if you possible can. Of course, this also holds true for using scp instead of ftp, although scp isn't as widely supported, yet.
- Daniel Golding
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Mr. James W. Laferriere Sent: Tuesday, July 31, 2001 11:25 AM To: nanog@merit.edu Subject: Re: telnet vs ssh on Core equipment , looking for reasons why ?
Hello All ,Thank you for the disertations & insight into the possible methods of compromising an authentication attempt .
But , I am really interested more in 'Why' each responsible indidvual(s) chose either telnet or ssh to manager their Core equipment .
ssh 1 ) Has been the encrypted authentication .
telnet 1 ) Has been legacy OS's / Equipment olny supporting telnet .
On Tue, 31 Jul 2001, Mr. James W. Laferriere wrote:
Hello All ,I have charged myself with trying to find a statistic on how many individuals responsible for IP core equipment recommend telnet or ssh & why particularly .I will summarize .
Tia ,JimL
+------------------------------------------------------------------+ | James W. Laferriere | System Techniques | Give me VMS | | Network Engineer | P.O. Box 854 | Give me Linux| | babydr@baby-dragons.com | Coudersport PA 16915 | only onAXP |
+------------------------------------------------------------------+
-- Dave Israel Senior Manager, IP Backbone Intermedia Business Internet
-- Ariel Biener e-mail: ariel@post.tau.ac.il PGP(6.5.8) public key http://www.tau.ac.il/~ariel/pgp.html
participants (5)
-
Alex Bligh -
alex＠yuriev.com -
Ariel Biener -
Dave Israel -
David Howe