Hi Nicolas, THANK YOU. I was going to post on it as another better solution for SSH Tunneling, but you have done it :) I will re-implement ssh-keys back, (and i will make sure this time it works from any client side, via using portable PuTTY, or PuTTY based, or openssh in linux/unix/macosx, or openssh in windows (obtain via cygwin), or other portable SSH-client software/solution, and will also pay attention on it so it does not leave any trace, keys, session-data, etc at client (Linux, Unix, Wndows, MacOSX) computers, so it will need some time). Since i'm looking for AND obviously doing it for higher security, than high-speed/fastness, i prefer to use : ECDSA based 256-bit (or 384-bit or 521-bit) key. How do i generate ECDSA key in CentOS ? and then, How do i use it with OpenSSH in CentOS ? (CentOS v6.3 , v6.4) Please suggest if you think another will be better and why. Pls suggest solution which are cost-free and trusted. As far as what i understand: * RSA, DSA both algorithm are asymmetrical. Both are now suitable when insecure channel/path/components exists in between communication of two participants. * DSA is faster for signature generation and when decrypting, but slower for validation or when encrypting. * RSA is generally faster for encryption, but slower in decryption. * ECDSA usually faster than both RSA & DSA, and also uses lesser bandwidth than both. * A 256-bit ECDSA key is (roughly) equivalent in strength to at-least a (256 x 4 Times = ) ~ 1024-bit DSA key, and can also treated as (roughly) close to strength of (Half of 256 = 256 / 2 = ) ~ 128-bit symmetric key (like, AES). * Both DSA & RSA now allows 2048-bits or longer keys. * DSA is made free to public by NIST. RSA's patent expired by 2000 so now free. Though Certicom has valid patent on ECC, but Curve25519 (ECDH) specifically is a different implementation, and not under those patent, (as Only certain/specific implementation technique(s) can be patended). And, RFC 6090 (published in Feb 2011) documented ECC techniques, some of which were published long time ago, which even if they were patented, such patents (for these previously published techniques) are now expired, and prior art also exist. So based on those, ECDSA is also free to use. * Verifying RSA signature requires less computational resources than DSA. * DSA uses shorter size signatures, so usually works better when bandwidth is lesser, whereas RSA usually works better when bandwidth is higher. * Since SSHv2, both DSA & RSA now use "Perfect Forward Secrecy" by using DSE (Diffie-Hellman-(Merkle) key Exchange) based transient/session key, so if a dsa/rsa private key file on server is compromised, then future ssh connections are compromised but past ssh connections (even if recorded) still remains better protected. * A very good random number generator function must be used by software(+hardware) for DSA, RSA. * According to Bruce Schneier, "both DSA and RSA with the same length keys are just about identical in difficulty to crack." * RSA, DSA, ECDSA, AES etc all can be attacked, has their limitations, weaknesses, issues, and various things in these are based on assumption. * When key-press/strokes, signals, etc are logged (or sent outside) during typing password/gen-key at end-point computers then such mechanisms are even lesser useful, and seems to be common in many device. And, when (one-side or) server is located on "Cloud", Hosting/Data-Center Service Providers, etc, or, on a remote computer where server-owner has no physical control over it (private key files), then such mechanisms are less useful against protected communication. Thanks in advance, -- Bright Star. Reference Reads: https://en.wikipedia.org/wiki/Public-key_cryptography https://en.wikipedia.org/wiki/RSA_%28algorithm%29 https://en.wikipedia.org/wiki/Digital_Signature_Algorithm https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange https://en.wikipedia.org/wiki/Elliptic_Curve_DSA https://en.wikipedia.org/wiki/ECC_patents http://security.stackexchange.com/questions/5096/rsa-vs-dsa-for-ssh-authentication-keys Received from Nicolas Thierry-Mieg, on 2013-04-04 10:22 AM: > Bry8 Star wrote: >> Hi, >> QUESTION: >> what implications are there when using the "root" or a root type of >> account via a port-forwarding ssh-tunnel inside (or on top of) >> another non-root type of user's ssh-tunnel ? >> >> Is such double layer of encryption brings more security or system >> still vulnerable same as single layer of SSH encryption ? >> > <snip> >> >> QUESTION: >> what is/are better practice(s) (to secure CentOS server related to >> SSH) ? >> >> QUESTION/Possible-SOLUTION: >> Should i remove the "root at 127.0.0.1" from "AllowUsers" and add >> "PermitRootLogin no" line in /etc/sshd_config file ? > > your current setup is a bit complex, I can't comment on whether it gains > you anything compared to direct ssh connection as whatever user you need > to be (not root), and relying on sudo to elevate your admin user's > privileges. > But yes I would recommend disabling root login, and using only keys if > you can (ie disabling passwords). > This could be a useful read: > http://wiki.centos.org/HowTos/Network/SecuringSSH > _______________________________________________ > CentOS mailing list > CentOS at centos.org > http://lists.centos.org/mailman/listinfo/centos > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP digital signature URL: <http://lists.centos.org/pipermail/centos/attachments/20130405/420ce2af/attachment-0004.sig>