I was doing a search for hosts at hostsearch.com and in their advanced search, they asked me if i wanted a host with Telnet and/or SSH. I have no idea what those mean. I would greatly appriciate any help in explaining these terms to me. Also, is it very necessary for a basic domain (a personal one with some photography, a weblog and such) to have these things?
Thanks in advance!

Telnet allows you to send commands to your server remotely. You have a program on your PC with a command prompt (similar to DOS if you're not sure what I'm talking about). You can then type commands in and they'll be sent to your server.

SSH is just a more secure form of Telnet.

It's useful mainly for more advanced users who want to do script debugging or compiling or monitor the server's performance etc.

I hope that helps. Someone might be able to give you a more precise definition...

As a general rule, if you don't know what it is, you certainly don't need it. :-)

Originally posted by Lawrence
Telnet allows you to send commands to your server remotely. You have a program on your PC with a command prompt (similar to DOS if you're not sure what I'm talking about). You can then type commands in and they'll be sent to your server.

SSH is just a more secure form of Telnet.


I'd change those around a little to:

SSH allows you to send commands to your server remotely. You have a program on your PC with a command prompt (similar to DOS if you're not sure what I'm talking about). You can then type commands in and they'll be sent to your server.

Telnet (just like rlogin, rsh, etc.) is a way of shooting yourself in the foot. Don't use it.

Originally posted by kwimberl
As a general rule, if you don't know what it is, you certainly don't need it. :-)

Not necessarily. I doubt many people understand what it means to repond to 80/TCP SYN packets with TCP SYN|ACK packets, but it's still quite necessary.:D

Whats wrong with telnet? I love it :D
Originally posted by cperciva


I'd change those around a little to:

SSH allows you to send commands to your server remotely. You have a program on your PC with a command prompt (similar to DOS if you're not sure what I'm talking about). You can then type commands in and they'll be sent to your server.

Telnet (just like rlogin, rsh, etc.) is a way of shooting yourself in the foot. Don't use it.

I have heard a lot of crap about telnet also, I like it, but apperently its unsafe to use it. I GUESS some reasons are it might be exploitable, and it doesent encrypt information, also I would syspect that more script kiddies look for telnet then ssh

Originally posted by cperciva
Telnet (just like rlogin, rsh, etc.) is a way of shooting yourself in the foot. Don't use it.

LOL :D

Originally posted by davidb
I have heard a lot of crap about telnet also, I like it, but apperently its unsafe to use it.

Not unsafe exactly, just less safe. As someone pointed out in another thread, often users check their mail with their user/pass, admins check server email, etc... so really if you wanted to be safe, you'd make sure every username/pass transmission is encrypted, not just telnet.

Although I try to be as safe as possible, I know I must have users who change their password from what I give them (something like H76n)RTyn^) ... to something like 'cat' ::shudder:: to make it easier for them to remember - anyone else worry about the same things?

Originally posted by Chicken
so really if you wanted to be safe, you'd make sure every username/pass transmission is encrypted, not just telnet.

Slight detail here: the insecurity of telnet comes from the fact that authentication is performed in plaintext combined with the fact that telnet is stateless. Even if an attacker fails to sniff the packet containing your username and password, as long as they can sniff a single packet they have a good chance of being able to inject packets -- and a single packet could contain "rm -rf /". Secure authentication is not sufficient; security requires that post-authentication packets cannot be forged.


Although I try to be as safe as possible, I know I must have users who change their password from what I give them (something like H76n)RTyn^) ... to something like 'cat' ::shudder:: to make it easier for them to remember - anyone else worry about the same things?

If you don't trust your users, then it doesn't matter how secure their passwords are: If someone can't cause damage maliciously, they cannot cause damage accidentally.

oh wow. i only left for a few hours and look how many replies i got! Thank you so much! This was extremely helpful!

Originally posted by cperciva


[SNIP]

If you don't trust your users, then it doesn't matter how secure their passwords are: If someone can't cause damage maliciously, they cannot cause damage accidentally.

It can indeed matter. It's not trusting the user, so much as it is someone more easily gaining access to a user's account that has a poor password, whom does have the knowledge nd ill intentions. While it's true that if a regular user can only really damage their own site, the main way attacker's gain access and root servers, is local exploits and that's usually a fact based on how easy the real account holder's on the system choose poor passwords and give attackers' the ability to gain access to the system to use their exploits. Of course, good passwords are hardly the biggest aspect in preventing attacks and improving security, but they certainly can play a big role.

Provided user's use SSH (or aren't given a shell at all, if they don't use it or want to or know how), use secure FTP and secure POP and SMTP or IMAP (depending) and have good passwords, it can help prevent a lot of possiblities of an attacker gaining the access they desire to compromise the system. Of course, no one will argue that those steps can be completely futile, unless a lot of other steps are taken to prevent exploits and users with good or bad intentions from doing any damage, or lessening the damage anyway. However, good passwords do remain semi-important and they certainly do matter.

Originally posted by Chicken
Although I try to be as safe as possible, I know I must have users who change their password from what I give them (something like H76n)RTyn^) ... to something like 'cat' ::shudder:: to make it easier for them to remember - anyone else worry about the same things?

*giggle!* i made that mistake once. was in a rush and made this newuser's password really easy, just his last name with one extra character tacked on at the end. sent it to him with a Stern Warning to change the password immediately upon first login.

i forgot about it for a while and then had a nagging feeling so went and checked. needless to say, he never bothered to change it. and he was supposed to be a web professional, too! that sort of thing annoys me mildly :angry: , so i locked his account and waited for him to squawk. i thought i would give him a new (and much more complicated) password when he finally realized and asked me to fix his login. oddly enough, he hasn't complained yet and it's been more than a month. and here i thought his clients were paying him to work on their site for them... heh. i should be so lucky!

learned my lesson. never gonna make THAT mistake again... :stickout

Originally posted by Tim_Greer
While it's true that if a regular user can only really damage their own site, the main way attacker's gain access and root servers, is local exploits and that's usually a fact based on how easy the real account holder's on the system choose poor passwords and give attackers' the ability to gain access to the system to use their exploits

That's my point. If you don't trust your users -- ie, if your system is secure enough that you don't have to trust your users -- then even if an attacker gains access to some user's account, they still won't be able to do anything apart from damaging that user's files.

If there are local root exploits for your system, then you're probably at much greater risk from your users than you are from someone else who has broken into a user's account.

Originally posted by cperciva


That's my point. If you don't trust your users -- ie, if your system is secure enough that you don't have to trust your users -- then even if an attacker gains access to some user's account, they still won't be able to do anything apart from damaging that user's files.

If there are local root exploits for your system, then you're probably at much greater risk from your users than you are from someone else who has broken into a user's account.

Certainly, you seem to look at it like I do. You intend to put user on the system, so there's your biggest problem. There's no way around that problem -- since the problem is simply that, you're allowing users (many of them) on a shared system access. People's concern, is that user's have access, so the problem is there and can not be avoided, being that in itself is the problem. All you can do, is simply try and make sure the system is more secure and less likely for any user to have the ability or control to do anything, be it they wanted to or not (of course, how would they by mistake?), instead of worrying about keeping people out. I agree, that it's more important to make sure the system is secure for any user, instead of trying to keep them out as a protective measure. In fact, I'm sure you've seen me state that many times on this board alone about my feelings about that.

However, the issue still remains, that most attacks are from non-account holders that have gained access to a user's account, due to poor passwords. Now, granted, once they are in, they are in anyway and a good password isn't going to help too much, but it does help prevent it some. _Most_ system compromises are done by stupid kids (or adults) trying to prove something to themselves or others, or just because they think it's fun and challenging, a goal, if you will.

Surely, the point is to be more concerned with the system's security, looking at it as any user can attack the server and any user can have their account compromised and used for an attack (which is the most likely scenario). However, and again, being that _most_ attacks are done by people that don't know much, use "cracker" tools, mainly from gaining access to accounts with poor passwords, tells us that good passwords do make a very large difference when it comes to stopping a high percentage of attacks -- because the higher percentage are done by ignorant system crackers that would likely not have gotten in otherwise, assuming the system is decently secured and they didn't get in through some service or whatever that shouldn't be there or hasn't been properly configured.

Again, I agree, that it's more important to make sure a user can't do anything malicious and be limited once they do gain access, instead of simply worrying if someone does gain access -- since, as you said, it's not an issue of if you can trust them or not. I'm simply saying, that even so, since there's almost always exploits, even if you do a good or excellent job of securing the server, a very good preventative measure, is to keep people out by having user's choose good passwords. For the 5th time, to emphasize this, I completely agree with you, but passwords/authentication will always be an issue, since if we could definitely control what user's could log in and definitely keep everyone else out, systems would be highly more secure, even if you do take the other steps that are indeed necessary, as we've both mentioned. Thanks for the comment and clearing that up... I'm just trying to be clear for the sake of the viewers of this thread, as you are. :-)

Originally posted by Tim_Greer
However, the issue still remains, that most attacks are from non-account holders that have gained access to a user's account, due to poor passwords.

<snip>

I'm simply saying, that even so, since there's almost always exploits, even if you do a good or excellent job of securing the server, a very good preventative measure, is to keep people out by having user's choose good passwords.

I'm saying not saying Cperciva is wrong, just that I don't fully think that, "even if an attacker gains access to some user's account, they still won't be able to do anything apart from damaging that user's files" is entirely correct. I'm not concerned with them changing some HTML files to say, "hAcKEd bY dUMBa$$", I'm more concerned with them basically having an account on the system, uploading as much warez and they can, spamming through the account, maybe they have telnet/SSH access (I don't offer it, but soe hosts do), and poking around the server, etc., etc., etc.

I don't know much about it myself, but what little I do know tells me that if I posted the servername, and a username and password on this board, the whole damn server would probably be taken over in a matter of minutes and either taken down or used in some way that wouldn't make me happy.

I don't think it is 'the' top defense tool one should use, just a good first line of defense and I know that when my users request passwords like '<insert their first name>' and I give them ^*%&gu&6, that some of them must change it.

Cperciva seems to know more about this than I do, so maybe I'm just overly paranoid, but somehow I think part of my paranoia is justified. I'd love it for everyone to tell me in a soft voice, "It's ok Chicken... it's ok..." :D

Originally posted by Chicken
I'm more concerned with them basically having an account on the system, uploading as much warez and they can, spamming through the account

You mean your users are allowed to do such things? You must trust them a lot -- which is my point.

A properly setup system limits what untrusted users can do. A properly setup system doesn't, for example, allow arbitrary users to send arbitrarily large amounts of email. (Or to spawn large numbers of processes, etc.)

As long as you don't trust your users their password integrity is not important.

Originally posted by cperciva


Not necessarily. I doubt many people understand what it means to repond to 80/TCP SYN packets with TCP SYN|ACK packets, but it's still quite necessary.:D

Who needs port 80 anyhow? :D

Originally posted by cperciva


You mean your users are allowed to do such things? You must trust them a lot -- which is my point.

A properly setup system limits what untrusted users can do. A properly setup system doesn't, for example, allow arbitrary users to send arbitrarily large amounts of email. (Or to spawn large numbers of processes, etc.)

As long as you don't trust your users their password integrity is not important.

But, the thing is, most users aren't out to do no good, whereas a system cracker probably is and will upload those warez files, SPAM from that user's account, etc. A good password can certainly help prevent that issue from coming up. Sure, user's can and should be restricted/limited anyway -- within reason, yet still allowing them to do what they want and need.

I agree, you can't use good passwords to really help secure the server from attack, but you can use good passwords to help secure the user from attack and having these things happen. Maybe it's a poor way for a lot of hosts that don't have very good security, to think they are securing their server... I'm sure it is and it might in a way. However, I'm not going to say it, or that alone, is going to do very much good.

The point again being, that if you allow user's access, you have a problem. They also don't need shell access to create a problem, as you know, as long as they have FTP or file manager access, control panel access, etc. and have the ability to use CGI, PHP, etc. Yes, indeed, if a server could be secured to where any user couldn't attack the system, abuse the system or whatever, then there'd be no need to worry about who has access to what account, other than root. However, that's not really possible, with how OSes are built, so you can't count on that. Even if that idea is the priority, which is a good idea, there's still going to be an issue if user's choose poor passwords. That is going to remain an issue.

A good working example. A long time ago, there was a guy in the news groups asking about cheap hosts. Someone recommended the pay option of Hypermart.net. I responded saying something like "Hypermart is okay for free hosting, but free or paid, if you care about your data, privacy or anything else, like someone being able to delete, alter or upload files to your account, don't use them. If you have static HTML pages, images and files you don't care if people see, see the source of or download, and maybe delete, then sure, go for it." Well, a guy that was arrogant responded, as a client of them, saying that I was just talking BS, and how the paid accounts didn't have that problem, said I was just unqualified and a joke.

I took his email and name, did a quick search, found his domain, verified it was the same person, and that he was indeed on a Hypermart server. I took the server's IP, did a search again, looked at the first match, that site had moved. Looked at the second match for that server name he was hosted on and found a domain and sub domain account/site. The site's name was some high school. I literally opened up my FTP client, typed in their username, just to see, and typed in the password of their school's mascot's name, which was right on their main page of their site. I was in. I wrote a script to backup his database and leave a message for him with new database information.

He promptly emailed me, thanking me, (I should note that he said I could try, and 2 minutes later, I did it), and said that he was wrong and asked if i knew of any decent hosts that were better secured for around the same price. I wasn't looking to or caring to suggest anyone else, just to show him. The point being, had that other user chosen a good password, I wouldn't have gotten in. Of course, yes, it is true that had the system been configured properly, that even if I did gain access to that other user's account, I couldn't have done anything to alter the other user's. But, the problem also exists, that there's almost always going to be something to do.

And out of all these things that almost always allow someone to do, it's usually something that's an exploit that not everyone will know about to get a patch or be able to hack to prevent it from being exploitable -- if that's a viable option at all, and there's many tools that are open to that and some that we need or want to run. Tools or programs that people don't know have the issue, or not yet. These are be used to attack the server, and any server will have a lot of programs that can be used for it. You can certain deny user's from programs and tools they shouldn't be able to use anyway, but there's so many things people can do. The idea, of course, as we agree upon, is to take away these dangers and possibilities, but that is not going to be easy for anyone, especially everyone.

Indeed, limited access, having rules and restrictions, can and do help. Also, implementing things like wrappers and filters, chrooting them on top of that, setting proper ownership, permissions and denying user's access to certain tools and programs and much more, will help and help make it almost impossible for user's to circumvent the system's security. However, problems still remain, in how systems are built, protocols and right down to the kernel. Sure, those of us that know and can do something about it, can look through the source, recognize and update, fix or revert back to the last good version of a program or tool, but how many people can do that? And, who's going to find this before you, since you're busy with all the other great number of things to secure a server?

What happens when one of these people can't remote access through a remote exploit and simply only need local access to use an exploit before you, bugtraq or anyone else knows about it, since you don't realistically have time to go through the source of every program and tool, and you'd surely miss something that other people will find anyway. All it can take to turn things around, is access to a user's account to get local access and use this exploit. A good password on that user's account could have prevented this, could have bought you time and gave you a little bit more security, and that is real, that is a fact.

Again, I am in no way suggesting or condoning people use more secure passwords and that that it even really is going to help (for most servers, it won't anyway), but it does make a difference. Depending on the circumstances, it can be important, even if not the most important. It is a step. provided people can't exploit a program or tool remotely and gain access other than locally, if they can't get that local access in the first place, it helps make your system safer. It's a fact, and good or poor passwords can make that much of a difference. Once again, I am also speaking of the fact that 90+% of all these type of exploits, both locally and remotely, are launched by moron's that don't know anything and are using "cracker tools", and a good password, even if it doesn't do much in some situations, can help prevent a lot of hassle, even if they aren't able to actually root the server or do some genuine damage.

I wholeheartedly support a policy of strong passwords for these reasons, as well as to prevent the user themselves from having to complain about their own site being wiped out too, which can cause headaches to have to deal with. There's no reason for weak passwords and there's no harm in having strong passwords. It's a policy I would suggest anyone consider implementing, but certainly to have the concern about more important things and not worry too much about the passwords. However, for the reasons above, it can make a difference, even on systems that have had good attention for security.

Well, that's just my thoughts on it, every system is different. In conclusion, it might or might not do much good, depending on the system, but it always does some good. Sure, there's more important things and an insecure system, is insecure anyway and passwords aren't much of an issue, but no matter the system, passwords are still and will remain an issue in some aspects and they will make a difference, even if a small amount.

Originally posted by Tim_Greer
They also don't need shell access to create a problem, as you know, as long as they have FTP or file manager access, control panel access, etc. and have the ability to use CGI, PHP, etc.

To avoid misleading anyone, it should also be pointed out that on a server running Sendmail you don't even need to use CGI: uploading a .forward file containing the line "|/usr/bin/perl -x" will allow an attacker to execute attacks via email.