I do not get ssh. Why is it more secure?
in [General Linux]
|
Prev: How to convert TrueType fonts to bitmapped fonts in Ubuntu
Next: I do not get ssh. Why is it more secure?
From: David Brown on 17 Jun 2010 09:36 On 17/06/2010 14:29, The Natural Philosopher wrote: > David Brown wrote: >> On 17/06/2010 11:12, Todd wrote: >>> Hi All, >>> >>> With this command: >>> >>> ssh -l todd -X 192.168.255.14 /usr/bin/VirtualBox >>> >>> I can run VirtualBox console on another computer with X11. >>> All I get is asked for my password. >>> >>> I don't get it. How is this any more secure that plain >>> old telnet? Both are just a user name and password. >>> You could hack it the same old way other services >>> are hacked by running the dictionary at them. I >>> do believe OPH Crack over on the Windows side calls >>> this "Rainbow tables". >>> >>> I ask this because I will be needing to open SSH (port 22) >>> for a vendor to get in on. And, well, I just don't get >>> the advantage of ssh over anything else. >>> >> >> Arrange with the vendor to use a non-standard port. If you open port >> 22 to the world, you'll get lots of unwanted attempts at breaking in. >> If you put your ssh server on port 12345, it will be free from attacks. >> >>> What am I missing? Is there a way to tighten ssh up? >>> >>> Many thanks, >>> -T >> >> ssh has a range of benefits over other remote solutions such as telnet >> or rsh. >> >> First is that the entire session is encrypted, so it can't be >> eavesdropped or modified under way (unlike telnet). As another poster >> has mentioned, this is less relevant in practice than many people >> think, but it's nice to have. >> >> You can use private/public keys instead of or as well as passwords. >> >> You can can store options for your ssh client for ports and other >> options, organised by server, which is very convenient if you need to >> connect to many servers. >> >> The traffic can be compressed, which is nice for slower links. >> >> You can tunnel other ports through the link - it's great for ad-hoc >> remote connections. >> >> You can use "scp" for copying files conveniently. >> >> You can arrange for multiple ssh sessions to share a single link, >> reducing overhead and link connection times. >> >> In short, it's securer and much more flexible than telnet or similar >> solutions. >> >> > However, none of these are really insurmountable by other means. > > Its only mire secure if you think your link can and will be > eavesdropped: In practice this is extremely unlikely. > I agree that it's very unlikely. But the cost of security is pretty minimal - the encryption takes very little of a modern processor's capacity. > And telnet is not something one uses for bulk transmission of data > anyway, so compression isn't really an issue. > You don't use telnet for bulk transmission - but you could well use ssh for bulk data. I certainly use it for that, either in the guise of "scp" or for tunneled connections of other kinds. > In short its probably an outdated tool that introduces (some) security > that you probably dont need anyway, and has attributes you probably wont > use either. > It may be a little "mature", but I know of nothing that can replace it. Telnet works well enough for a simple remote command shell - but you could hardly call ssh "outdated" and recommend telnet as a replacement! Note also that with telnet, you have to type in the user name and password - making it a real pain for any sort of automation. With ssh, you can use password-less public key authentication. Did you actually read what I wrote above? The advantages I listed for ssh are features that I use on a regular basis. There are, to my knowledge, /no/ alternatives that come close to that. > Its history goes back to the days of repeater style coaxial ethernet > networks, and large campuses, where students could watch sysadmins > typing in passwords to the main servers, and use them to gain access. It > wasa fine tool in that scenario. > > These days anyone bothered about security tends to use something at a > much lower level. e.g. firewalling to prevent access except from defined > places, and/or VPN networks to routinely encrypt ALL traffic. > I also make regular use of vpns. When you have a connection that you want to make permanent, setting up a vpn is a good solution. But it is overkill for when you want to make a connection for a specific purpose. What you are suggesting is to go through all the effort of setting up appropriate vpns, firewall rules, routing, etc., so that you could then use telnet to get a remote connection. Or you could just use ssh. And what about when the vpn's are not working? That happens - perhaps there is an equipment failure, a line failure, a configuration mixup, or whatever. A ssh "backdoor", properly secured of course, is a huge timesaver. > And the deployment of switching technology has made packet sniffing a > much harder thing to do. > If you think ssh is just "encrypted telnet" you've missed the point.
From: General Schvantzkoph on 17 Jun 2010 09:44 On Thu, 17 Jun 2010 13:29:48 +0000, Douglas Mayne wrote: > On Thu, 17 Jun 2010 02:12:25 -0700, Todd wrote: > >> Hi All, >> >> With this command: >> >> ssh -l todd -X 192.168.255.14 /usr/bin/VirtualBox >> >> I can run VirtualBox console on another computer with X11. All I get is >> asked for my password. >> >> I don't get it. How is this any more secure that plain old telnet? >> Both are just a user name and password. You could hack it the same old >> way other services are hacked by running the dictionary at them. I do >> believe OPH Crack over on the Windows side calls this "Rainbow tables". >> >> I ask this because I will be needing to open SSH (port 22) for a vendor >> to get in on. And, well, I just don't get the advantage of ssh over >> anything else. >> >> What am I missing? Is there a way to tighten ssh up? >> >> Many thanks, >> -T >> > telnet is worse in two ways: > 1. The username/password pair is not encrypted and is sent in the clear > over the network. > 2. Once the session is setup, that session's data is not encrypted and > is sent in the clear over the network. > > At first glance, the second problem appears to be the main point of the > ssh program. That is, its job is to provide an encrypted tunnel to > protect the communications on the channel. However, the first problem is > also important. Security could be compromised if it were possible to > capture passwords in the clear- the same attack that works against > telnet. ssh authentication has been designed to avoid that pitfall. > > ssh also allows multiple ways of authentication: shared secret > (password), public/private ssh keys, and others. The username/password > exchange does not send data in the clear, but as you note, it may still > be subject to brute force and dictionary attacks. To eliminate that > possibility, switch to using public/private authentication. There are > many tutorials on the web explaining how to do this. It takes some time > and practice to learn how to set this up, but it is worth it. Remember, > be careful not to lock yourself out while you are learning how to do it > correctly. > > Also, for internet exposed hosts, consider installing a rate-limited > firewall rule against repeated login attempts from bad hosts. In a LAN > environment, a firewall rule is probably overkill. However, I still use > certificate authentication, though. I use it because it allows the ssh- > agent to automatically log me in without a password prompt. If you disable password authentication I'm not sure that the firewall rule is necessary, however if you do want to do that then the script denyhosts is available as a package on Fedora and CentOS, I don't know about other distros. I require RSA authentication and I use denyhosts, but I also keep my pants up with both a belt and suspenders (that's for real, it's not just an expression).
From: F. Michael Orr on 17 Jun 2010 09:50 On Thu, 17 Jun 2010 13:29:00 +0100, The Natural Philosopher wrote: > David Brown wrote: >> On 17/06/2010 11:12, Todd wrote: >>> Hi All, >>> >>> With this command: >>> >>> ssh -l todd -X 192.168.255.14 /usr/bin/VirtualBox >>> >>> I can run VirtualBox console on another computer with X11. All I get >>> is asked for my password. >>> >>> I don't get it. How is this any more secure that plain old telnet? >>> Both are just a user name and password. You could hack it the same old >>> way other services are hacked by running the dictionary at them. I do >>> believe OPH Crack over on the Windows side calls this "Rainbow >>> tables". >>> >>> I ask this because I will be needing to open SSH (port 22) for a >>> vendor to get in on. And, well, I just don't get the advantage of ssh >>> over anything else. >>> >>> >> Arrange with the vendor to use a non-standard port. If you open port >> 22 to the world, you'll get lots of unwanted attempts at breaking in. >> If you put your ssh server on port 12345, it will be free from attacks. >> >>> What am I missing? Is there a way to tighten ssh up? >>> >>> Many thanks, >>> -T >> >> ssh has a range of benefits over other remote solutions such as telnet >> or rsh. >> >> First is that the entire session is encrypted, so it can't be >> eavesdropped or modified under way (unlike telnet). As another poster >> has mentioned, this is less relevant in practice than many people >> think, but it's nice to have. >> >> You can use private/public keys instead of or as well as passwords. >> >> You can can store options for your ssh client for ports and other >> options, organised by server, which is very convenient if you need to >> connect to many servers. >> >> The traffic can be compressed, which is nice for slower links. >> >> You can tunnel other ports through the link - it's great for ad-hoc >> remote connections. >> >> You can use "scp" for copying files conveniently. >> >> You can arrange for multiple ssh sessions to share a single link, >> reducing overhead and link connection times. >> >> In short, it's securer and much more flexible than telnet or similar >> solutions. >> >> > However, none of these are really insurmountable by other means. > > Its only mire secure if you think your link can and will be > eavesdropped: In practice this is extremely unlikely. > On a privately controlled network, yes. However, on anything crossing the Internet, one cannot assume this to be true. If one were serious about compromising an organization, then all one would have to do would be to set up a man in the middle router, which would silently capture all traffic to/from a site. If this traffic were not encrypted, this would be a problem. > And telnet is not something one uses for bulk transmission of data > anyway, so compression isn't really an issue. > <SNIP> > These days anyone bothered about security tends to use something at a > much lower level. e.g. firewalling to prevent access except from > defined places, and/or VPN networks to routinely encrypt ALL traffic. Firewalling is a necessary tool, but offers no protection against common exploits such as MitM or IP spoofing. VPNs are inherently no more secure than an SSH connection, and it can be argued that for user level access are in fact less secure. The main weakness of a VPN is that the remote machine becomes at least partly integrated into the local site. For a site-to-site VPN, this is fine. However, for user-level access one has to rely on the remote machine's security, which is an unknown. There are tools such as clean access to deal with this, but they are, IMO, something of a kludge. SSH connections, in the hands of someone who actually knows what they are doing, have the benefit of treating a remote machine as a remote machine.
From: David Brown on 17 Jun 2010 09:55 On 17/06/2010 15:14, J G Miller wrote: > On Thu, 17 Jun 2010 13:28:46 +0200, David Brown wrote: > >> Arrange with the vendor to use a non-standard port. If you open port 22 >> to the world, you'll get lots of unwanted attempts at breaking in. If >> you put your ssh server on port 12345, it will be free from attacks. > > Or better setup your router or software firewall with IPTABLES so that > only connections from the vendor's IP address will be accepted on port 22. > That makes sense if the vendor won't work with a non-standard port. But while locking access to a single source IP is often a good idea, it can sometimes be difficult - perhaps your contact at the vendor doesn't know their IP, or perhaps it will change (maybe they have more than one outgoing route, or perhaps the vendor will connect from different sites). It's all a matter of how many layers of protection and paranoia you want. But using a non-standard port is typically very simple to implement, and is very effective. Another good trick is to limit the connection rate on your ssh port - that will stop any dictionary attacks. > A similar rule can also be added to /etc/hosts.allow if using tcpd > wrappers, as you should be. > That's overkill. The iptables rules control the incoming traffic, and limit it to a particular source address if you want. Why would you bother repeating the same rules again? It does nothing for the security, but adds to the complexity and gives more chance for confusion when things are not working as you expect. > Also for more security, create a group eg ssh-users, and add only those > users allowed to ssh to the machine in that group. Then change > the sshd configuration to allow only users in that group ssh-users > to connect. > That sort of thing depends entirely on the setup, and what sort of external access you want to allow. But it certainly makes sense to limit the external access - at a minimum, root login by ssh should normally be disabled. > For an even higher level of security, only allow (open)VPN connections > with certificate and password, for ssh to occur over those. Again, that's overkill. A vpn doesn't add anything in security over the ssh connection. Use public/private key access (perhaps also with passwords) for the ssh access if you want.
From: J G Miller on 17 Jun 2010 10:18
On Thu, 17 Jun 2010 15:55:42 +0200, David Brown wrote: > The iptables rules control the incoming traffic, and > limit it to a particular source address if you want. Why would you > bother repeating the same rules again? If the filtering for outside traffic is done at the router, then you may not want to allow all hosts by default inside the network to ssh into that machine. The best security model is not one where everything is open and then you lockdown the undesirables, but the other way around where everything is locked down and then only open up those things which you wish to allow. > A vpn doesn't add anything in security over the > ssh connection. Two points 1) with VPN you have the VPN port open rather than the ssh port which will of course stop ssh drive by attempts. 2) with VPN you can revoke a certificate thereby stopping further access from the user with that certificate > Use public/private key access (perhaps also with > passwords) for the ssh access if you want. I completely agree that ssh with keys exchange only as the means of authentication is the best use of ssh and in general provides adequate security even over the Internet. |