Colour code is implemention to servers.

Colour code is implemention to servers.

Edit /.profile  file of root user with “echo ‘\033[41;97m’” =>Red background with white foreground.

Scope of SSH key usage additional controls and restrictions

==================================================
Scope of SSH key usage additional controls and restrictions:

A) Additional controls in usage of SSH keys in our managed environments.
The directive has mandated that SSH key use be limited and controlled to meet all regulations and compliance.
This should also ensure approved and monitored access to shared and/or privileged userIDs.
Scan all systems.

==================================================
B) Review of existing SSH keys, removing keys which are deemed no longer necessary, labelling SSH keys (as per regulations and

compliance std) that are required to be retained and ensuring control restrictions are in-place on all keys.

Priority:
1) Internet
2) Intranet

1. Review all in-scope SSH keys
Review all SSH keys (private/public) across all in-scope servers.
a) If SSH key(s) are no longer required, remove/delete these (follow any account specific change management processes if required)


b) If SSH key(s) are required to be retained, you are required to label these and provide additional control restrictions on the key

(see steps below).
b.1) Identify ownership and label keys
Each public key must be assessed to determine ownership and labelled according to firm standards.
This label must be in the comment field of the public key, and it must be in gecos label format, starting and ending with the

characters "!!".
Example: rest-of-key...9MOT2QZw== !!Owner name and id!!
b.2) RSA - 1024-bit minimum key length is acceptable however transition to 2048-bit minimum key length is recommended. Where the

substantial extra computational burden of 2048 bits is significant or prohibitive, consider modulus sizes of 1280 or 1536.
Example: ssh-keygen -t rsa -b 1024 -f id_rsa

CASE A: Individual owned SSH keys
 SSH keys owned by an individual, must have their key pair re-generated with a pass-phrase.
Individually owned SSH keys must not exist without a passphrase.
(Passphrases must have a minimum number of 5 words each of minimum length of 4 characters and are exempt from the syntax rule for mix

alphabetic and non-alphabetic characters. All other password rules are applicable.)

NOTE: Before creating new keys ensure you have determined all the endpoints where you will have to distribute the new public key and

where required follow any account specific change management processes.

CASE B: Non-individual owned SSH keys
 SSH keys which are functional/system/non-individual, must have both the FROM and COMMAND options specified within the public key to

restrict/define access proprieties of the key pair.
1)Add the "from" option to the beginning of your public key entry in the authorized_keys file.
from="xxx.xxx.xxx.xxx" (where xxx.xxx.xxx.xxx is the IP address of the host you are allowing to access this server with the private

key)
2)Also add the "command" option to the beginning of your public key entry in the authorized_keys file.
command="/path of command" (this will for any access to only run the given command)
Example: from="10.10.1.10",command="/usr/bin/script" ssh-dss AZDAAAB3NzaC1kc3MAAACB/xIe.....9MOT2QZRWd== !!Owner name and id!!
   

CASE C: Customer owned SSH keys
 SSH keys which are owned by the customer, must be labelled accordingly as customer owned.
All customer owned IDs will be consolidated and communicated through to each customer with a risk communication.
==================================================