SSH vs VPN : Kenapa bukan DNS? Kenapa bukan proxy??
Entri ini ialah rumusan, kesimpulan, atau konklusi dari entri-entri Mr.Hac yang sebelumnya mengenai Secure Shell (SSH) Tunneling dan Virtual Private Network (VPN)..antara anonimiti dan keselamatan, antara kebebasan berinternet dan privasi, dan juga antara niat dan tujuan, 2 kaedah berbeza ini telah mencapai satu konklusi yang konkrit (perghhh..)

Beberapa pelawat/pembaca yang datang singgah ke blog ini bertanyakan soalan itu kepada Mr.Hac..jawapannya mudah sahaja..anda yang baru membaca blog ini, dan terus bertanyakan soalan seperti itu, Mr.Hac anggarkan anda tidak bekerja lagi, atau mungkin bekerja tetapi bukan di syarikat korporat/sektor kerajaan, dan boleh jadi anda telah disekat oleh Penyedia Servis Internet (ISP) iaitu STREAMIX, dan lain-lain ISP lagi dari melayari 10 laman perkongsian fail yang telah diarahkan oleh SKMM..jadi Mr.Hac yakin dan pasti anda hanya disekat oleh firewall atau sistem/perisian sekatan yang kurang fungsinya, dan boleh juga dikatakan lemah..anda pastinya tidak pernah lagi disekat oleh firewall yang digunakan oleh syarikat-syarikat korporat, contohnya Websense, Sonic Wall, tak lupa juga Barracuda..

Disebabkan itu Mr.Hac TIDAK menulis tutorial menggunakan DNS ataupun Proxy, cuma yang ada Proxy-Based Software iaitu Ultrasurf..ini adalah kerana DNS dan Proxy tidak mampu melepasi sekatan internet yang dibuat oleh perisian sekatan/firewall itu tadi..Mr.Hac harap anda lebih jelas dengan matlamat Mr.Hac supaya anda semua dapat melayari laman web yang disekat dengan tutorial yang lebih berhasil dan mantap berbanding menggunakan DNS atau Proxy yang ternyata sesuai untuk firewall yang lemah, dan juga lebih sesuai untuk golongan pemula..jadi sesiapa yang telah membaca entri ini Mr.Hac harap anda tolong jangan tanya lagi apa kegunaan DNS, Proxy, SSH Tunneling, mahupun VPN..Hac akui tutorial yang ditulis agak TEKNIKAL dan perlukan pemahaman yang bukan tinggi, juga usaha untuk memahaminya bukan sedikit, tetapi jika ada kesungguhan, Hac pasti anda boleh melakukannya!

Berikut adalah pertikan dari beberapa laman web mengenai perbezaan antara SSH dan VPN:

SSH: Secure Shell is a program for logging into a remote machine and for executing commands on a remote machine. It is intended to replace telnet, ftp (fetch), rlogin and rsh, and provide secure encrypted communications between two untrusted hosts over an insecure network. (from the openbsd man page).
SSH encrypts all traffic (including passwords) to effectively eliminate eavesdropping, connection hijacking, and other network-level attacks. Additionally, SSH provides a myriad of secure tunnelling capabilities, as well as a variety of authentication methods. (from the openssh front page.)

VPN: Virtual Private Network. A private network that is configured within (or to travel across) a public network in order to protect data or for other reasons. In this case, the University of Minnesota built a VPN to allow high-speed internet access users (DSL and cablemodem users) access to U. resources from their homes, like those who use the modem pool have.
The VPN will encrypt data sent from home until it gets to the VPN server on campus, but after that, the data is unencrypted as it passes over the local U. network.

SSH (Secure Shell)

SSH was designed as a secure (encrypted) way to log into a remote system.
SSH secures shell logins and specific ports on a one-to-one basis.
SSH has been extended over the years to support additional services such as scp (secure copy) and sftp (secure ftp) which basically encrypt the cp or ftp connection in an ssh session.
SSH works at the port level and can secure individual connections.
SSH runs at what’s called the application layer. This means that it works on a specific port (typically 22) using defined protocols for communication and is an end-to-end solution (i.e. one machine connected to port 22 on another machine).

VPN (Virtual Private Network)

VPN connects networks rather than individual hosts.
VPN establishes one connection that securely tunnel traffic to an entire network (one connection to a server, provides access to the entire network resources).
VPN works at the transport layer. This means it handles ALL communication between two points on the network. It doesn’t care about what kind of traffic you’re handling (http, ftp, ping, nfs, dns, and yes, even ssh).
VPN has no concept of what any of the higher-level protocols actually do. It just knows that it encrypts this packet, sends it on its way and decrypts it at the other end. Therefore even if you had a VPN tunnel established between two points, you still need to use ssh to open a shell on the remote machine, or use a web browser to access a web site, or use an ftp client to up/download files. The difference is that the VPN adds a layer of security to otherwise non (or, at least, less) secure protocols.

Beza yang jelas antara keduanya:

Security

Hands down, in the general scheme of things, I would say VPN has this area won. While SSH does in fact have a high security standard, the way VPN handles encryption is more intelligent. This is pretty much all because of VPN’s encapsulation method (which will be covered again later) that adds an additional security measure that SSH doesn’t.

For those who aren’t familiar with encapsulation, especially with VPN, here’s a general overview. When you connect through a VPN tunnel, the TCP/IP packets have more overhead. This is due in part to the VPN service placing an encryption header on top of the packet itself. While this does slow down traffic (which will be covered later as well), companies have gotten wise to this technology and added measures to make sure this cannot be tampered with. This is generally done with a token (such as a 6-digit RSA SecurID) which authenticates the user, instead of using (just) a username and password.

In the realm of SSH, the protocol it uses is pretty intensive when it comes to security. The fundamental flaw to this, though, is when a key isn’t used. In previous articles I gave a step-by-step guide on how to set this up, and there’s a major reason for this. When you log in via SSH without using a key, your log in information is sent via plain text. Now, if you’re only connecting to a home computer that’s setting right next to you, it’s almost never an issue. But, say you’re at work and you want to check the iostats on the server, sending your data via plain text would not be the logical choice. That’s basically telling everyone to log into your server. VPN doesn’t have this issue, as the encapsulation header doesn’t contain anything damaging to the user itself, as all the data is inside the packet underneath the encapsulation header.

Speed

This is the one that gets to me the most here. For anyone that’s used both protocols, I’m sure they will agree that SSH is the faster of the two. Fortunately, the reason is simple.

In the last point, I talked about how VPN has that encapsulation header to provide an additional layer of security. While it adds that extra sense, it comes at a great price. With VPN, what happens is (not necessarily like this but the basic idea is there), the packet payload is segregated (as a TCP/IP packet length can only be 1500 bytes). This means that less data reaches the destination, requiring more packets to be sent, increasing bandwidth. Once the encapsulation header has been added to the packet, and reaches the destination, the destination then has to remove the header to get the payload from the packet. So, basically, a website that generally takes about 5 seconds to load (for example), can take 10-15 seconds (if you’re lucky).

SSH, however, plays nicely with the data. With or without a key, packets don’t take as long to get from A to B. There is no overhead (i.e.: extra headers) to deal with when it comes to SSH, and while there is a slight speed performance hit, even when using SSH as a proxy that same page can take only 2 seconds longer to load.

Ease of Use

For the administrator setting up the service, this sort of depends. Since most Linux flavors have at least 1 VPN solution in their repos, and I have yet to run into one that doesn’t have an SSH server/client in them, it’s pretty easy for the administrator to just run a single command to install it all. This category, though, is really intended for the users the administrator will have to support with said software.

When I worked on the Ford help desk, I got a lot of calls every day asking for help on how to get VPN to work. While the calls were easy, there was never an easy “click here to solve it all” button we could push. Granted, most of the time it dealt with either a transport/tunneling issue, or sometimes even a port issue, there was a lot more calls than we should’ve received from it. Then there was also the problem of the previously-mentioned SecurIDs desynching. Again, a very easy fix, but it seemed if it wasn’t one thing it was another. I can’t fault the user though, completely, as the e-mail documentation (read: a couple of paragraphs) didn’t go into any detail what-so-ever to assist the user.

SSH, while I never really dealt with it in the same manner as VPN, is a lot easier to use. The thing is, using a key makes the task even easier. Unfortunately there’s not a lot to really say here, as it also depends on how you use SSH (i.e.: PuTTy, OpenSSH client, another SSH client, etc…), but it all pretty much amounts to the same result. It’s all relatively easy to set up, and the administrator can simply pass out a config file (like a script file for Linux) to make the task even easier if it uses a generic key.

Configuration

Every server is different, which makes this category a bit hard to judge. However, in general SSH is easier to manage, especially when you have a big network. The reason why I say this is because, at least OpenSSH, uses one, maybe two configuration files you have to modify generally. Probably the hardest task is setting it up to use keys instead of password authentication. VPN does make this task easier, though, by offering an online configuration (at least OpenVPN does). Which in the end does make configuration even easier, while you only have to worry about the network configuration (i.e.: making sure VPN access from outside is possible).

Conclusion

When it comes down to it, I personally prefer SSH. VPN would be great if I was running a medium or large network, and/or was super paranoid. However, SSH with key-authentication satisfies my necessities just fine. Basically, if you’re using VPN, know that it might (probably will) need extra configuration compared to it’s sibling, but adds a hefty amount of extra security SSH doesn’t (at a price). If you prefer, you could also set up both, and use VPN when it’s not time-critical, while SSH is used for those moments where you’re against the clock.

Rujukan/Petikan Dari:

ITKnowledgeExchange

Mahmudonline

geo.umn.edu

*dan juga beberapa forum dalam talian

Views: 7