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: Todd on 17 Jun 2010 05:12 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
From: David Brown on 17 Jun 2010 07:28 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.
From: The Natural Philosopher on 17 Jun 2010 08:29 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. And telnet is not something one uses for bulk transmission of data anyway, so compression isn't really an issue. 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. 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. And the deployment of switching technology has made packet sniffing a much harder thing to do.
From: J G Miller on 17 Jun 2010 09:14 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. A similar rule can also be added to /etc/hosts.allow if using tcpd wrappers, as you should be. 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. For an even higher level of security, only allow (open)VPN connections with certificate and password, for ssh to occur over those.
From: Douglas Mayne on 17 Jun 2010 09:29
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. -- Douglas Mayne |