[CentOS] Using "root" Type User Via Forwarding-SSH-Tunnel Inside Non-Root SSH Connection

Fri Apr 5 09:44:05 UTC 2013
Bry8 Star <bry8star at yahoo.com>

Hi Nicolas,


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 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

Thanks in advance,
-- Bright Star.

Reference Reads:

Received from Nicolas Thierry-Mieg, on 2013-04-04 10:22 AM:
> Bry8 Star wrote:
>> Hi,
>> 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>
>> what is/are better practice(s) (to secure CentOS server related to
>> SSH) ?
>> Should i remove the "root at" 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-0005.sig>