Why Install Telnet by Default?
I am not a security expert by any means, nor necessarily a "purist", when it comes to installing only the apps I need to run. I do install some apps that I want to tinker with, even though I may not use them regularly. However, I understand that we should avoid using telnet because it is "insecure". Yet, telnet is still installed by default on SUSE, when the secure alternatives seem to be more appropriate. I assume there is a reason for this. I ask, because I deselected telnet when I installed SUSE 10.0, and duringa repair process, my system reported that telnet was a core app. If we should avoid using it, shouldn't we avoid installing it to begin with? Thanks in advance for your input. Don -- Web Developer Oakdale Christian Fellowship http://matheteuo.org/
On Thu, 8 Dec 2005, WebDev wrote:
[... Why installing insecure utils like telnet? ...]
/The/ SuSE-Linux distribution is located in the consumer market by novell. You will hardly see /consumers/ using a cisco device which offers SSH login but you will see a lot of /consumers/ running devices like access points which only offer telnet logins - if any... Best regards Henning Hucke -- While your friend holds you affectionately by both your hands you are safe, for you can watch both of his. -- Ambrose Bierce, "The Devil's Dictionary"
Telnet is only insecure because it sends usernames and passwords in the clear and that's a bad idea over the internet because it can be snooped. However, on a LAN where you want to tinker, this is fine. It's installed by default because some routers MAKEyou use it and it's kindof dumb not to install it. That's all. Having it installed isn't insecire but using it to connect to a machine over the internet COULD be. -Allen
Allen, On Thursday 08 December 2005 08:37, Allen wrote:
Telnet is only insecure because it sends usernames and passwords in the clear and that's a bad idea over the internet because it can be snooped. However, on a LAN where you want to tinker, this is fine.
It's also not secure in that it sends _all_ the data, inbound and outbound, unencrypted.
It's installed by default because some routers MAKE you use it and it's kindof dumb not to install it. That's all. Having it installed isn't insecire but using it to connect to a machine over the internet COULD be.
As others have pointed, out, it's also a handy diagnostic tool even if it has limited utility for its original purpose. Lastly, if it's used only between hosts on a secure intranet, there's no reason not to use it and it clearly places less demand on CPU since there's no encryption and decryption computation to perform on all traffic in and out.
-Allen
Randal Schulz
Randall R Schulz wrote:
Allen,
On Thursday 08 December 2005 08:37, Allen wrote:
Telnet is only insecure because it sends usernames and passwords in the clear and that's a bad idea over the internet because it can be snooped. However, on a LAN where you want to tinker, this is fine.
It's also not secure in that it sends _all_ the data, inbound and outbound, unencrypted.
Just like postfix, sendmail, exim, qmail, zmailer and every other MTA. More people send more confidential data by unencrypted email than they do by telnet, and I don't recall anyone saying "don't use email." Yeah, sometimes someone emntions it'sinsecure, usually they don't say why, but as soon as someone mentions telnet, they say, Ooh, don't do that, it's insecure." It's the telnet _protocol_ that lacks security features: don't blam the servers and clients for doing what the telnet STDs say they must. I use ssh rather than telnet, rsh, rexec etc because it's more convenient. Mostly, I control the wire or go through a vpn I control.
John, On Thursday 08 December 2005 09:02, John Summerfield wrote:
Randall R Schulz wrote:
Allen,
On Thursday 08 December 2005 08:37, Allen wrote:
Telnet is only insecure because it sends usernames and passwords in the clear and that's a bad idea over the internet because it can be snooped. However, on a LAN where you want to tinker, this is fine.
It's also not secure in that it sends _all_ the data, inbound and outbound, unencrypted.
Just like postfix, sendmail, exim, qmail, zmailer and every other MTA.
So? My point is no less valid because it applies elsewhere, too.
More people send more confidential data by unencrypted email than they do by telnet, and I don't recall anyone saying "don't use email."
More people are fools than wise, yes?
Yeah, sometimes someone mentions it's insecure, usually they don't say why, but as soon as someone mentions telnet, they say, Ooh, don't do that, it's insecure."
It's the telnet _protocol_ that lacks security features: don't blame the servers and clients for doing what the telnet STDs say they must.
I didn't think there was any blame going on here. And if you're going to take that approach, then you must acknowledge that there are secure email transfer formats that are widely implemented.
I use ssh rather than telnet, rsh, rexec etc because it's more convenient. Mostly, I control the wire or go through a vpn I control.
That depends, I guess, on how you define convenience. I know of nothing about configuring or using SSH-based services that is more convenient than using plain old (non-secure) telnet. (Even if SSH-based services are taken out of the picture entirely, I still have to type several passwords many times each day, so keyed access isn't going to make my life much more convenient.) Randall Schulz
Randall R Schulz wrote:
John,
On Thursday 08 December 2005 09:02, John Summerfield wrote:
Randall R Schulz wrote:
Allen,
On Thursday 08 December 2005 08:37, Allen wrote:
Telnet is only insecure because it sends usernames and passwords in the clear and that's a bad idea over the internet because it can be snooped. However, on a LAN where you want to tinker, this is fine. It's also not secure in that it sends _all_ the data, inbound and outbound, unencrypted. Just like postfix, sendmail, exim, qmail, zmailer and every other MTA.
So? My point is no less valid because it applies elsewhere, too.
telnet's the least of the hazards (in terms of its use), the greatest (in terms of thw warnings).
More people send more confidential data by unencrypted email than they do by telnet, and I don't recall anyone saying "don't use email."
More people are fools than wise, yes?
Yeah, sometimes someone mentions it's insecure, usually they don't say why, but as soon as someone mentions telnet, they say, Ooh, don't do that, it's insecure."
It's the telnet _protocol_ that lacks security features: don't blame the servers and clients for doing what the telnet STDs say they must.
I didn't think there was any blame going on here.
I don't know about that, some wre saying "telnet" by which one usually means the telnet client program, some said "telnetd" referring to the server (and so accepting "telnet" refers to the client).
And if you're going to take that approach, then you must acknowledge that there are secure email transfer formats that are widely implemented.
I use ssh rather than telnet, rsh, rexec etc because it's more convenient. Mostly, I control the wire or go through a vpn I control.
That depends, I guess, on how you define convenience. I know of nothing about configuring or using SSH-based services that is more convenient than using plain old (non-secure) telnet. (Even if SSH-based services are taken out of the picture entirely, I still have to type several passwords many times each day, so keyed access isn't going to make my life much more convenient.)
Using ssh, I can arrange for secure passwordless authentication. That's a greate convenience I could never achieve with telnet, though I did sort of fudge it with an expect script. ssh can forwar X sessions so I can run kpat on a remote computer, with the display on mine. That's a great convenience I could manage wiht rsh only by allowing all X connexions to all computers I'd want to run kpat on. Doubtless you'd see security problems with that. More seriously than kpat, I generally do software updates in a remote xterm displaying locally. It's a great convenience that I don't have to fiddle with rhosts and use xhost for every combination of system I might want to maintain and computer from which I want to do it and that changes in IP address and/or host name at either end don't matter. It's often useful that ssh can forward ports, so I can use a port number on my system (a laptop right now) to access a service on any LAN where I can connect This is a greate convenience when 1. I need to reconfigure an http-based router, printer etc on a LAN that I can reach, where the device doesn't know where _I_ am. 2. I need to connect to an IPP printer on the office LAN from home: I can forware a port from my home desktop to my office desktop and have at it. 3. Ditto, connecting to a work database. The convenience of passwordless authenticated login extends to other facilities such as scp, rsync, tar (shoulkd I want to backup to a remote tape drive) and plain ordinary file copying, whether ising tar, dd or something else, over a pipe. The fact that these connexions are encrytpted is nice, of course, and I might even put up with some inconvenience sometimes to obtain those benefits, but I don't have tomake the choice, in my ordinary use they are completely unimportant. It's when using security is more convenient that not using it that most people will use security. I'm sure that, even in these times, if you surveyed homes or cars in your local suburb, you'd find a few unlocked (even when unattended), because locking them is inconvenient.
John, On Thursday 08 December 2005 16:39, John Summerfield wrote:
...
I use ssh rather than telnet, rsh, rexec etc because it's more convenient. Mostly, I control the wire or go through a vpn I control.
That depends, I guess, on how you define convenience. I know of nothing about configuring or using SSH-based services that is more convenient than using plain old (non-secure) telnet. (Even if SSH-based services are taken out of the picture entirely, I still have to type several passwords many times each day, so keyed access isn't going to make my life much more convenient.)
Using ssh, I can arrange for secure passwordless authentication. That's a greate convenience I could never achieve with telnet, though I did sort of fudge it with an expect script.
I'm surprised so many very security-conscious people think that passwordless is such a good thing. Now you've made physical access to your computer all that is required to gain access to all the other hosts for which you've set up passwordless access. What's more, from the perspective of the administrators of those systems, it's you who has accessed their resources and you'll get the blame, at least initially, for any malicious actions. I don't find passwords so onerous that I've supplanted them with passwordless access. I suppose it's just another aspect of being a control freak.
...
Randall Schulz
Randall R Schulz wrote:
John,
On Thursday 08 December 2005 16:39, John Summerfield wrote:
...
I use ssh rather than telnet, rsh, rexec etc because it's more convenient. Mostly, I control the wire or go through a vpn I control. That depends, I guess, on how you define convenience. I know of nothing about configuring or using SSH-based services that is more convenient than using plain old (non-secure) telnet. (Even if SSH-based services are taken out of the picture entirely, I still have to type several passwords many times each day, so keyed access isn't going to make my life much more convenient.) Using ssh, I can arrange for secure passwordless authentication. That's a greate convenience I could never achieve with telnet, though I did sort of fudge it with an expect script.
I'm surprised so many very security-conscious people think that passwordless is such a good thing. Now you've made physical access to your computer all that is required to gain access to all the other hosts for which you've set up passwordless access. What's more, from the perspective of the administrators of those systems, it's you who has accessed their resources and you'll get the blame, at least initially, for any malicious actions.
Physical acces involves electronic security (locks and monitored alarms), mechanical keylocks and having your photo taken while on the job. Once you have physical access, passwords are moot. Or detailed knowledge. Our data has little commercial value; if you want a site to cause mahem to the internet, there are easier pickings. Half a dozen unsecured wireless APs where I live for starters.
On Fri, Dec 09, 2005 at 09:19:29AM +0800, John Summerfield wrote:
Randall R Schulz wrote:
John,
On Thursday 08 December 2005 16:39, John Summerfield wrote:
...
I use ssh rather than telnet, rsh, rexec etc because it's more convenient. Mostly, I control the wire or go through a vpn I control. That depends, I guess, on how you define convenience. I know of nothing about configuring or using SSH-based services that is more convenient than using plain old (non-secure) telnet. (Even if SSH-based services are taken out of the picture entirely, I still have to type several passwords many times each day, so keyed access isn't going to make my life much more convenient.) Using ssh, I can arrange for secure passwordless authentication. That's a greate convenience I could never achieve with telnet, though I did sort of fudge it with an expect script.
I'm surprised so many very security-conscious people think that passwordless is such a good thing. Now you've made physical access to your computer all that is required to gain access to all the other hosts for which you've set up passwordless access. What's more, from the perspective of the administrators of those systems, it's you who has accessed their resources and you'll get the blame, at least initially, for any malicious actions.
Physical acces involves electronic security (locks and monitored alarms), mechanical keylocks and having your photo taken while on the job. Once you have physical access, passwords are moot.
Oh man the number of Hospitals I've been able to walk around in through their IT staff saying I'm a consultant or something. Quite easy to defeat all of that. I mean what are you going to do take out the floppy drive? And the CD drive? LOL ANything yo can do can be taken apart or picked.
Or detailed knowledge. Our data has little commercial value; if you want a site to cause mahem to the internet, there are easier pickings. Half a dozen unsecured wireless APs where I live for starters.
-- Check the headers for your unsubscription address For additional commands, e-mail: suse-security-help@suse.com Security-related bug reports go to security@suse.de, not here
On Thu, 8 Dec 2005, Randall R Schulz wrote:
[...] I'm surprised so many very security-conscious people think that passwordless is such a good thing. Now you've made physical access to your computer all that is required to gain access to all the other hosts for which you've set up passwordless access. What's more, from the perspective of the administrators of those systems, it's you who has accessed their resources and you'll get the blame, at least initially, for any malicious actions.
Erm... Passwordless access to the other computers implies in the case of SSH that you first enable the necessary keys with your passphrase for your session. And even this you can cut down to the need to /regularly/ reauthenticate. I don't get your point though. Best regards Henning Hucke -- Semiconductor: part time band leader
Henning, On Thursday 08 December 2005 22:18, Henning Hucke wrote:
On Thu, 8 Dec 2005, Randall R Schulz wrote:
[...] I'm surprised so many very security-conscious people think that passwordless is such a good thing. Now you've made physical access to your computer all that is required to gain access to all the other hosts for which you've set up passwordless access. What's more, from the perspective of the administrators of those systems, it's you who has accessed their resources and you'll get the blame, at least initially, for any malicious actions.
Erm... Passwordless access to the other computers implies in the case of SSH that you first enable the necessary keys with your passphrase for your session. And even this you can cut down to the need to /regularly/ reauthenticate.
E.g., my office mate has passwordless access set up for all the hosts he regularly accesses (my company has literally thousands of hosts, of which we need to interact with dozens, if not hundreds, on a fairly regular basis). All I have to do is walk over to his desk, say, when he goes to lunch, and do things that no one can readily tell were not done by him. On the other hand, he cannot do the reverse to me, since I haven't set up passwordless access to any of these hosts.
I don't get your point though.
Now?
Best regards Henning Hucke
Randall Schulz
Randall R Schulz said:
All I have to do is walk over to his desk, say, when he goes to lunch, and do things that no one can readily tell were not done by him.
On the other hand, he cannot do the reverse to me, since I haven't set up passwordless access to any of these hosts.
And what prevents him to install a keylogger under your account? Passwords for remote access give you no additional security if your local computer is not secured. I really hope you're using some kind of session lock.
Michel, On Thursday 08 December 2005 23:52, Michel Messerschmidt wrote:
Randall R Schulz said:
All I have to do is walk over to his desk, say, when he goes to lunch, and do things that no one can readily tell were not done by him.
On the other hand, he cannot do the reverse to me, since I haven't set up passwordless access to any of these hosts.
And what prevents him to install a keylogger under your account? Passwords for remote access give you no additional security if your local computer is not secured. I really hope you're using some kind of session lock.
Actually, I trust him. We all have fairly open access to each other's computers, but we're all just programmers. And the company reserves the right to monitor our work and our computers, so for all I know, there are such monitors already. I was just making up an example of how passwordless access can undermine security. Randall Schulz
On Thu, Dec 08, 2005 at 10:38:45PM -0800, Randall R Schulz wrote:
Henning,
On Thursday 08 December 2005 22:18, Henning Hucke wrote:
On Thu, 8 Dec 2005, Randall R Schulz wrote:
[...] I'm surprised so many very security-conscious people think that passwordless is such a good thing. Now you've made physical access to your computer all that is required to gain access to all the other hosts for which you've set up passwordless access. What's more, from the perspective of the administrators of those systems, it's you who has accessed their resources and you'll get the blame, at least initially, for any malicious actions.
Erm... Passwordless access to the other computers implies in the case of SSH that you first enable the necessary keys with your passphrase for your session. And even this you can cut down to the need to /regularly/ reauthenticate.
E.g., my office mate has passwordless access set up for all the hosts he regularly accesses (my company has literally thousands of hosts, of which we need to interact with dozens, if not hundreds, on a fairly regular basis).
All I have to do is walk over to his desk, say, when he goes to lunch, and do things that no one can readily tell were not done by him.
Note that if you leave an ssh or telnet session open to a remote host and leave for lunch, regardless of how you authenticated, someone can do the same to the remote host. Assuming he's using ssh-agent and not passwordless keys, your colleague has a couple of options available to him, if he's willing to look at the ssh-add manpage. You may wish to introduce him to "ssh-add -D", which he can run before leaving for lunch to delete all identities currently stored in the agent. Once he returns from lunch, he can then ssh-add them back. Alternatively, he can do 'ssh-add -x' to lock the agent with password, and 'ssh-add -X" with the same password to unlock it again. He can also use a timeout via ssh-add -t <time>. If he's using passwordless keys; well, ssh-agent(1) and ssh-add(1) are your friends. -- Steve Beattie SUSE Labs, Novell Inc. <sbeattie@suse.de> http://NxNW.org/~steve/
On Fri, 2005-12-09 at 08:39 +0800, John Summerfield wrote:
Using ssh, I can arrange for secure passwordless authentication. That's a greate convenience I could never achieve with telnet, though I did sort of fudge it with an expect script.
why not just use the ssh trusted keys? mybox$ cd ~/.ssh mybox$ ssh-keygen -t dsa -b 1024 -P '' -f id_dsa mybox$ scp id_dsa.pub user@otherbox:.ssh/authorized_keys The scp will ask for your password. After that, you can ssh, scp or whatever without typing the password. Mike
On Fri, 9 Dec 2005, John Summerfield wrote:
[...]
It's also not secure in that it sends _all_ the data, inbound and outbound, unencrypted.
Just like postfix, sendmail, exim, qmail, zmailer and every other MTA.
Erm... Depends. If your MTA client supports it you can send mails to my system through a TLS tunnel (STARTTLS) and my systems sends mails in the same way if the remote server supports it.
[...]
Best regards Henning Hucke -- The world is moving so fast these days that the man who says it can't be done is generally interrupted by someone doing it. -- E. Hubbard
John Summerfield wrote:
Randall R Schulz wrote:
It's also not secure in that it sends _all_ the data, inbound and outbound, unencrypted.
Just like postfix, sendmail, exim, qmail, zmailer and every other MTA.
More people send more confidential data by unencrypted email than they do by telnet, and I don't recall anyone saying "don't use email."
Allow me to introduce you to PGP and GPG, encryption for e-mail :) Funny story: I started using Enigmail (GPG plugin for Mozilla mail client) about 5 years ago. For six months, all of the mail I sent out everywhere was GPG-signed. Then I upgraded Mozilla, it broke the (not yet supported) Enigmail plugin, and I couldn't be bothered to fix it. So I started sending out mail with no digital signatures. Now, according to the usage models of public key signed documents, I *should* have started receiving complaints from people about "Crispin usually signs his mails, and this is not signed; are you an imposer or what?" But that *never* happened. Not once. This convinced me that very, very few people actually check digital signatures, and thus they are of very little value in casual correspondence :( Digital encryption, on the other hand, has direct specific utility, in that you can encrypt sensitive content to a specific person any time you like. I do use that fairly regularly, at least with my correspondents who are PGP/GPG aware. Full disclosure: I am on the PGP.com Technical Advisory Board, and they actually make a (Linux-based) mail server appliance that substantially addresses this very problem, resulting in most corporate communications being encrypted. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering, Novell http://novell.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Thursday 2005-12-08 at 22:28 -0800, Crispin Cowan wrote:
Funny story: I started using Enigmail (GPG plugin for Mozilla mail client) about 5 years ago. For six months, all of the mail I sent out everywhere was GPG-signed. Then I upgraded Mozilla, it broke the (not yet supported) Enigmail plugin, and I couldn't be bothered to fix it. So I started sending out mail with no digital signatures.
Now, according to the usage models of public key signed documents, I *should* have started receiving complaints from people about "Crispin usually signs his mails, and this is not signed; are you an imposer or what?" But that *never* happened. Not once. This convinced me that very, very few people actually check digital signatures, and thus they are of very little value in casual correspondence :(
If the MUA kept track of signatures, it could warn if someone started to send non signed email. This info could be kept with the address book; for example, mozilla stores "prefers html" info. In the suse-linux-s list we had a period when somebody impersonated other people, creating quite a nasty turmoil. Many of the old hands there use pgp/gpg signatures routinely. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFDmaE9tTMYHG2NR9URAk87AJwPho8v2rEtSYHo9lUQE/oMazT6xgCeO9kp vZFgejfhEfoqDiY4qAyMLdA= =OTas -----END PGP SIGNATURE-----
On Thu, Dec 08, 2005 at 01:18:34AM -0500, WebDev wrote:
I am not a security expert by any means, nor necessarily a "purist", when it comes to installing only the apps I need to run. I do install some apps that I want to tinker with, even though I may not use them regularly. However, I understand that we should avoid using telnet because it is "insecure". Yet, telnet is still installed by default on SUSE, when the secure alternatives seem to be more appropriate. I assume there is a reason for this.
I ask, because I deselected telnet when I installed SUSE 10.0, and duringa repair process, my system reported that telnet was a core app. If we should avoid using it, shouldn't we avoid installing it to begin with?
The telnet protocol is unsafe, telnet the program is just another program and can be used "safe" locally or for non-login purposes. Ciao, Marcus
Although Telnet and RSH are insecure , it is very important to install those application . If you are managing SAN , NAS and any other Network Devices where they not support SSH from a UNIX/Linux box , then Telnet and RSH are the only means of communication . Thanks & Regards, Shashi Kanth WebDev wrote:
I am not a security expert by any means, nor necessarily a "purist", when it comes to installing only the apps I need to run. I do install some apps that I want to tinker with, even though I may not use them regularly. However, I understand that we should avoid using telnet because it is "insecure". Yet, telnet is still installed by default on SUSE, when the secure alternatives seem to be more appropriate. I assume there is a reason for this.
I ask, because I deselected telnet when I installed SUSE 10.0, and duringa repair process, my system reported that telnet was a core app. If we should avoid using it, shouldn't we avoid installing it to begin with?
Thanks in advance for your input. Don
WebDev wrote:
I am not a security expert by any means, nor necessarily a "purist", when it comes to installing only the apps I need to run. I do install some apps that I want to tinker with, even though I may not use them regularly. However, I understand that we should avoid using telnet because it is "insecure". Yet, telnet is still installed by default on SUSE, when the secure alternatives seem to be more appropriate. I assume there is a reason for this.
I ask, because I deselected telnet when I installed SUSE 10.0, and duringa repair process, my system reported that telnet was a core app. If we should avoid using it, shouldn't we avoid installing it to begin with?
Thanks in advance for your input. Don
I have not installed a telnet _server_ in years, not just because it's insecure, but because ssh is easier to use. However, I alwasy install a telnet client because it's so very useful for chatting to smtp servider (eg postfix, sendmail) to test access throught firewalls, check mail problems and such. Other service telnet's gor for testing are pop3, imap, nntp and even ssh: summer@Xenosaurus:~> telnet localhost 22 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. SSH-1.99-OpenSSH_4.1 Protocol mismatch. Connection closed by foreign host. summer@Xenosaurus:~> This tellms ther service is working, and the version of the software there. I can even have a conversation with webservers, tho netcat is better for that.
telnetd is what you don't want running. Telnet is very useful tool for debugging internet application protocols. think beyond a remote shell. You can telnet to port 25 to see whats up with a mail server, 80 for a web server etc. the telnet client is very important and useful tool. On Thu, 8 Dec 2005, WebDev wrote:
I am not a security expert by any means, nor necessarily a "purist", when it comes to installing only the apps I need to run. I do install some apps that I want to tinker with, even though I may not use them regularly. However, I understand that we should avoid using telnet because it is "insecure". Yet, telnet is still installed by default on SUSE, when the secure alternatives seem to be more appropriate. I assume there is a reason for this.
I ask, because I deselected telnet when I installed SUSE 10.0, and duringa repair process, my system reported that telnet was a core app. If we should avoid using it, shouldn't we avoid installing it to begin with?
Thanks in advance for your input. Don -- Web Developer Oakdale Christian Fellowship http://matheteuo.org/
-- Check the headers for your unsubscription address For additional commands, e-mail: suse-security-help@suse.com Security-related bug reports go to security@suse.de, not here
Quoting WebDev <webdev@matheteuo.org>:
I am not a security expert by any means, nor necessarily a "purist", when it comes to installing only the apps I need to run. I do install some apps that I want to tinker with, even though I may not use them regularly. However, I understand that we should avoid using telnet because it is "insecure". Yet, telnet is still installed by default on SUSE, when the secure alternatives seem to be more appropriate. I assume there is a reason for this.
I ask, because I deselected telnet when I installed SUSE 10.0, and duringa repair process, my system reported that telnet was a core app. If we should avoid using it, shouldn't we avoid installing it to begin with?
Thanks in advance for your input. Don
By default, is installed the telnet CLIENT. you can use it for connect to a telnet server, smtp by hand, o any purpose, but the telnet server is NOT installed, you need to isntall it.!
On Thursday 08 December 2005 09:44 am, Hipolito Gonzalez wrote:
Quoting WebDev <webdev@matheteuo.org>:
I am not a security expert by any means, nor necessarily a "purist", when it comes to installing only the apps I need to run. I do install some apps that I want to tinker with, even though I may not use them regularly. However, I understand that we should avoid using telnet because it is "insecure". Yet, telnet is still installed by default on SUSE, when the secure alternatives seem to be more appropriate. I assume there is a reason for this.
I ask, because I deselected telnet when I installed SUSE 10.0, and duringa repair process, my system reported that telnet was a core app. If we should avoid using it, shouldn't we avoid installing it to begin with?
Thanks in advance for your input. Don
By default, is installed the telnet CLIENT. you can use it for connect to a telnet server, smtp by hand, o any purpose, but the telnet server is NOT installed, you need to isntall it.!
Hey, thanks to all who responded. That does clarify things a bit! Don -- Web Developer Oakdale Christian Fellowship http://matheteuo.org/
participants (14)
-
Allen -
Carlos E. R. -
Crispin Cowan -
Dana Hudes -
Henning Hucke -
Hipolito Gonzalez -
John Summerfield -
Marcus Meissner -
Michel Messerschmidt -
Mike Branda -
Randall R Schulz -
shashi -
Steve Beattie -
WebDev