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 ?
DETAILS:
In CentOS (6.3 & 6.4) server side i have done these: (1) Created a user named "administrator". Then by using visudo command, i allowed "administrator" to have higher level of access & permission, similar/close to the "root" user, (not exactly same though). http://wiki.centos.org/TipsAndTricks/BecomingRoot (Basically this "administrator" user has maintenance related software running privilege).
(2) Created a user named "non-root", a standard/normal user.
(3) In /etc/ssh/sshd_config file i have modified the default configurations into this: # File: /etc/ssh/sshd_config port NNN10 protocol 2 SyslogFacility AUTHPRIV AllowUsers non-root root@127.0.0.1 administrator@127.0.0.1 PasswordAuthentication yes PermitEmptyPasswords no ChallengeResponseAuthentication no GSSAPIAuthentication yes GSSAPICleanupCredentials yes UsePAM yes AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE AcceptEnv XMODIFIERS X11Forwarding no Banner /etc/issue.net Subsystem sftp /usr/libexec/openssh/sftp-server # End of File: /etc/ssh/sshd_config
Above config allows only "non-root" user to connect with CentOS server from internet. And "administrator" or "root" can must/only connect using local ip address 127.0.0.1.
In /etc/issue file and in /etc/issue.net file i have placed such text info: *********************************** NOTICE / WARNING TO USERS * This computer system is private property of its owner, Bry8Star. * This message is shown from hostname.sld.tld * It is for AUTHORIZED use only. Any unauthorized or improper use of this system will result in CIVIL and CRIMINAL PENALTIES ... * ... * Your connection IP ADDRESS, PORT, and TIME info etc are recorded by this computer. ***********************************
In /etc/profile file, i have placed these below 13 lines just above the "unset i" line, at bottom side: if [ -n "$SSH_CLIENT" ] then set $SSH_CLIENT echo "Your current connection coming from IP Address $1 using port $2, to this computer." else if [ -n "$SSH_CONNECTION" ] then set $SSH_CONNECTION echo "Your current connection coming from IP Address $1 using port $2, to this computer." else echo "Your current connection's IP Address & port could not be shown for now." fi fi
In /etc/profile.local file, i have placed these below 13 lines at bottom side:
if [ -n "$SSH_CLIENT" ] then set $SSH_CLIENT echo "You have connected from IP Address $1 using port $2" else if [ -n "$SSH_CONNECTION" ] then set $SSH_CONNECTION echo "You have connected from IP Address $1 using port $2" else echo "User's IP Address could not be shown" fi fi
Above codes allow me to see what IP:port is currently being used. And after login opensshd by default shows last/previous connection's IP-address or reverse-domain. This helps to see instantly which IP is being used right now or who is attempting to login in simple way. Ofcourse log can show more detailed info.
And in client side (user side), i'm using PuTTY or PuTTY based or other SSH client software, with such configurations:
SSH-client software has 3 connection profiles.
The "ssh-client-01" connection ssh-profile is configured for regular user "non-root", and connects to ip.address.numbers:port (hostname.sld.tld:NNN10) (sld = 2nd level domain, tld = top level domain). This connection profile is also configured to create one encrypted port-forwarding tunnel through the SSH-tunnel: where, local port NNN11, is port-forwarded, to the (local-)port NNN10 inside CentOS server (hostname.sld.tld).
The "ssh-client-02" connection ssh-profile is configured for user "administrator", and connects to local ip address 127.0.0.1 on port NNN11 (127.0.0.1:NNN11). This connection profile itself has no port-forwarding tunnels. It uses the forwarding-tunnel of "ssh-client-01" to create SSH-tunnel, toward the ssh-server port NNN10 of CentOS server.
The "ssh-client-03" connection ssh-profile is configured with user "root", and connects to local ip address 127.0.0.1 on port NNN11 (127.0.0.1:NNN11). This connection profile itself has no port-forwarding tunnels. It uses the forwarding-tunnel of "ssh-client-01" to create SSH-tunnel, toward the ssh-server port NNN10 of CentOS server.
I first connect with CentOS server using "ssh-client-01", then i connect again with CentOS server using the "ssh-client-02".
In this way "ssh-client-02" (for "administrator") goes through the encryption layer of "ssh-client-01" (for "non-root").
If i need to use "root" level access/privilege, i do these:
sudo one-command options
For multiple commands i do these:
su - a-command options another-command options exit
To switch into another user account (like "GUIuser1", "non-root2") without disconnecting, i do:
su GUIuser1 su non-root2
The "ssh-client-03" ssh-profile i use for exceptional purpose, when i absolutely must have to use the "root" account directly, only then.
QUESTION: How can i configure opensshd related settings, so that, it shows current ip-address & port used by the current user who is trying/attempting to login ? BEFORE user types in the password.
I have placed a text "This is \o | Now it is \t \d | Connection is using \l" in /etc/issue file and also in /etc/issue.net file, but it does not work, just appears as verbatim, (escape sequenced special variables do not get translated/replaced by special values).
I want to show the user who is attempting to login, his/her IP-address, port, time, etc to him/her, every time before typing password.
QUESTION: what is/are better practice(s) (to secure CentOS server related to SSH) ?
QUESTION/Possible-SOLUTION: Should i remove the "root@127.0.0.1" from "AllowUsers" and add "PermitRootLogin no" line in /etc/sshd_config file ?
Thanks in advance, -- Bright Star.
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@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
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-authenti...
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@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@centos.org http://lists.centos.org/mailman/listinfo/centos
Am 05.04.2013 11:44, schrieb Bry8 Star:
How do i generate ECDSA key in CentOS ? and then, How do i use it with OpenSSH in CentOS ? (CentOS v6.3 , v6.4)
You'll have to install OpenSSH release 5.7 or newer. Standard CentOS 6 still ships with OpenSSH 5.3 which doesn't know about ECDSA yet.
FYI, PuTTY doesn't support ECDSA either. You might be better off staying with tried-and-true RSA.
Tilman Schmidt wrote:
Am 05.04.2013 11:44, schrieb Bry8 Star:
How do i generate ECDSA key in CentOS ? and then, How do i use it with OpenSSH in CentOS ? (CentOS v6.3 , v6.4)
You'll have to install OpenSSH release 5.7 or newer. Standard CentOS 6 still ships with OpenSSH 5.3 which doesn't know about ECDSA yet.
FYI, PuTTY doesn't support ECDSA either. You might be better off staying with tried-and-true RSA.
I missed the beginning of this thread - why are you looking at ECDSA?
Personally, I'm unfamiliar with it... but we are required to use PIV cards at work, and for those poor folks on Windows, we have putty-cac on their machines, which works just fine. http://www.risacher.org/putty-cac/
mark
-
Bry8 Star -
m.roth＠5-cent.us -
Nicolas Thierry-Mieg -
Tilman Schmidt