/host=master/subsystem=elytron/key-store=httpsKS:add(path="${jboss.home.dir}/ssl/jboss.jks", credential-reference={clear-text=jboss@123}, type=JKS) 2.Connect JBOSS Cli mode to configure keystore, key-manager and ssl-context in Elytron
It is better to always remove temp and wstemp when there is any update with application or re-deploy the application . But safer to take backup of the complete profile before making any deletion .
profile_root//temp and profile_root//wstemp these are the location of the temporary files in Websphere Application server .
WebSphere Application Server uses multiple temporary locations for many reasons. This post explains the most commonly used temporary files, why they are used and when they can be removed. This blog will also explain the files and directories that can be removed under the profile direction with caution.
Important:
Be careful in deleting any temporary, cache and log files in WebSphere Application Server!
Before making any changes to the environment , take a backup of the profile. It can be a tape backup, using the backupconfig tool, or using the manageprofile -backupProfile option.
Let's describe the different files and their locations:
profile_root/wstemp Usage: wstemp is a workspace temporary directory. Any changes that you make to the configuration are stored in the wstemp directory temporarily. For example, if you are changing the heap size for an application server, the change is stored in the wstemp location until you save the changes. The concept is same for any administrative client, such as the Integrated solution console, wsadmin or JMX, that you use to make the changes.
Caution: The WebSphere Application Server administrative console stores a preferences.xml file in install_root/wstemp/<workspace_id>. This file contains user preferences on administrative console layout and actions. It is created when you log onto the administrative console. If you remove this file, you lose the user preferences; however, the preferences can be created again the next time you log onto the administrative console.
Do not delete the wstemp files when the server is running (especially deployment manager or node agent servers). This approach can cause unexpected results. Also, do not delete the files when you are unsure about the changes that you made to the configuration. Save any pending changes, stop the deployment manager or node agent, which depends on whether you are removing the dmgr wstemp or node wstemp, and then delete the wstemp files.
Why remove these files?: Files in the profile_root/wstemp directory can be removed. Restart the server process after removal. Because the directory is used by multiple clients, some times you might see multiple files and subdirectories left behind in this directory. For example, when you use the ConfigService MBean to make changes to configuration and you do not discard the session in the code, this directory will never get deleted. Another reason is corruption in the workspace. Corruption can happen when multiple users make changes to the same configuration at the same time.
profile_root/temp Usage: The temp directory is used by multiple WebSphere components. Two good examples are compiled Java ServerPages (JSP) files and web service cache files. Compiled JSP class files (servlets) are stored in this location. The directory might get regenerated when you invoke the JSP again. However, you might experience a performance issue when you invoke the JSP for the very first time after the JSP compiled files have been removed.
Caution: Be cautious if you have a web services application deployed on the node. The wscache.xml is generated during the deployment process and stored under the temp directory. You have to redeploy the web service application to generate the wscache.xml again. You may experience some performance issue with large and complicate webservices application
Why remove these files?: Corrupted JSP files or any non-root permission issues might cause the server start up issue.
Never delete any other files or directories for WebSphere Application Server unless otherwise directed by the IBM Support team.
It is better to always remove tmp and cache when there is any update with application or re-deploy the application . But safer to take backup of the complete directory before making any deletion .
Recently when working with new application update I found that just bouncing/ restarting server is not enough, we will also need to clean up the cache so that new changes take effect. We will see how to clean temporary directories in Weblogic .
Find out the Domain directory under which our Managed instance folder's exist . Some customised Weblogic domain existing on a different location .If you dont know the location then on the Weblogic installation location find domain_registry.xml file . In this file you can see the list of Domain's created and it's paths .
Each managed server have its own tmp and cache directory .
--> Shut down Server.
--> Delete the contents of the folder ORACLE_HOME/user_projects/domains/your_domain/servers/your_server/tmp…
You can also delete ORACLE_HOME/user_projects/domains/your_domain/servers/your_server/cache
-->Restart Server.
You can also do something like this . In your startup script you can add delete statements so that every time the server restarted new tmp and cache will be re-created .
Note: Do not delete any other directories under the server . If you deleted then restoration is difficult and lead to startup issues .
- SSL 3.0 and TLS 1.0 are susceptible to known attacks on the protocol; they are disabled entirely.
- Disabling TLS 1.1 is (as of August 2016) mostly optional; TLS 1.2 provides stronger encryption options, but 1.1 is not yet known to be broken. Disabling 1.1 may mitigate attacks against some broken TLS implementations.
In addition, you can use SSL server which accepts strong encryption only by adding following directives too
~~~~~~~
SSLHonorCipherOrder on
SSLCompression off
SSLSessionTickets off
~~~~~~~
- Enabling SSLHonorCipherOrder ensures that the server's cipher preferences are followed instead of the client's.
There will a situation that the admin account is locked or no back up id to unlock or reset the admin id or completely forget the password then we may need to reset Weblogic Admin security.
Windows
Linux/AIX/Solaris
Assuming Domain path : cd D:\ABC\ABCDomain\
Assuming Domain path : /u01/ABC/ABCDomain/bin
cd D:\ABC\ABCDomain\bin and run below command
cd /u01/ABC/ABCDomain/bin and run below command
setDomainEnv.cmd
. ./setDomainEnv.cmd [ dot then space ]
cd D:\ABC\ABCDomain\security\
cd /u01/ABC/ABCDomain/security
move DefaultAuthenticatorInit.ldift [ Rename the file ]
As a part of OS user authentication there is a possibility to exchange the keys between ID's on same or different OS so that they can communicate without password . it is call password less authentication . Using this one can login to the server with our any "Entering password" / do file transfer from the script where we don't require to Enter password .
In this Post we will use same Server with 2 ID's . We will see how to connect one to another with password then will see how we can configure password less authentication .
In the organisation we may have server to server authentication mostly . some time with in the same server between multiple id's it may need to exchange for ease of day to day operations .
You want to use Linux and OpenSSH to automate your tasks. Therefore you need an automatic login from host A / user source to Host B / user destination. You don't want to enter any passwords, because you want to call ssh from a within a shell script.
How to Create a New User in Linux
To create a new user account, invoke the useradd command followed by the name of the user.
For example to create a new user named username you would run:
Set some password for each of the source and destination id's using passwd userid command
root@ip-172-31-14-154 destination]# passwd source
Changing password for user source.
New password:
BAD PASSWORD: The password fails the dictionary check - it is based on a dictionary word
Retype new password:
passwd: all authentication tokens updated successfully.
[root@ip-172-31-14-154 destination]#
[root@ip-172-31-14-154 destination]#
[root@ip-172-31-14-154 destination]# passwd destination
Changing password for user destination.
New password:
BAD PASSWORD: The password fails the dictionary check - it is based on a dictionary word
Retype new password:
passwd: all authentication tokens updated successfully.
[root@ip-172-31-14-154 destination]#
password of source is zaq12wsx and password of destination is mko09ijn
Let us see how we can do ssh from source to destination . Some OS will have tectia where sshg3 and scpg3 are available instead of ssh and scp
[source@ip-172-31-14-154 ~]$ ssh destination@ip-172-31-14-154
The authenticity of host 'ip-172-31-14-154 (172.31.14.154)' can't be established.
ECDSA key fingerprint is SHA256:bASX/U9HJi3iu0CUsUY+VcYlZR4mE8/b1tJQcl69RpM.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'ip-172-31-14-154,172.31.14.154' (ECDSA) to the list of known hosts.
destination@ip-172-31-14-154: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
[source@ip-172-31-14-154 ~]$
Update /etc/ssh/sshd_config with PasswordAuthentication yes if it was no and then restart sshd service to get rid of the above error
[root@ip-172-31-14-154 destination]# grep -i PasswordAuthentication /etc/ssh/sshd_config
#PasswordAuthentication yes
PasswordAuthentication yes
# PasswordAuthentication. Depending on your PAM configuration,
# PAM authentication, then enable this but set PasswordAuthentication
[root@ip-172-31-14-154 destination]# systemctl restart sshd
[root@ip-172-31-14-154 destination]#
SSH from Source to Destination . Now it will ask to enter destination id password
With Password we are able to authenticate from source to destination id successfully . Now we will see how we can make this password less using the public and private keys of the id's .
Let's do the password authentication by generating a pair of public and private keys of id's and exchange for authentication using below command
ssh-keygen -t rsa -b 4096
bit size can be 2048,1024,3072 or 4098 or any other bit size that supports
Run the command for source id
source@ip-172-31-14-154 ~]$ ssh-keygen -t rsa -b 4096
Generating public/private rsa key pair.
Enter file in which to save the key (/home/source/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/source/.ssh/id_rsa.
Your public key has been saved in /home/source/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:jtcQnDlr00yb91sOVgNn4dH4Gj0cqu79GJ2pZ+Kv3mA source@ip-172-31-14-154.us-east-2.compute.internal
The key's randomart image is:
+---[RSA 4096]----+
| +.|
| . o o.+|
| * . .o*.|
| B o .=oo|
| S = o +o|
| + + o .o.+|
| . o o E++.|
| . .oo*B |
| ..oBO+.|
+----[SHA256]-----+
[source@ip-172-31-14-154 ~]$ cd .ssh/
[source@ip-172-31-14-154 .ssh]$ ls -lrt
total 12
-rw-r--r--. 1 source source 192 May 2 04:49 known_hosts
-rw-r--r--. 1 source source 776 May 2 05:04 id_rsa.pub
-rw-------. 1 source source 3422 May 2 05:04 id_rsa
[source@ip-172-31-14-154 .ssh]$
Run the same command for destination id
[destination@ip-172-31-14-154 ~]$ ssh-keygen -t rsa -b 4096
Generating public/private rsa key pair.
Enter file in which to save the key (/home/destination/.ssh/id_rsa):
Created directory '/home/destination/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/destination/.ssh/id_rsa.
Your public key has been saved in /home/destination/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:V8THYedkP6waQjWcxK+4uFITKsk6ul7gXbqW6m+KDO8 destination@ip-172-31-14-154.us-east-2.compute.internal
The key's randomart image is:
+---[RSA 4096]----+
| +=o.o.+|
| .=o.+=.|
| . o. oo|
| .. . .. .|
| .. ... S.o... |
|. o+o. o o..o |
|...+o . o .. |
|++.+.. . . |
|BOEo ... |
+----[SHA256]-----+
[destination@ip-172-31-14-154 ~]$
ssh-keygen command will create 2 files one id_rsa [ Private key ] and id_rsa.pub [ public key ]
Note : For Source id to connect to Destination then source public key need to upload to destination
When i try to connect still asking password . so trying to un on debug mode vith -vvv
[source@ip-172-31-14-154 .ssh]$ ssh destination@ip-172-31-14-154 -vvv
OpenSSH_8.0p1, OpenSSL 1.1.1g FIPS 21 Apr 2020
debug1: Reading configuration data /etc/ssh/ssh_config
debug3: /etc/ssh/ssh_config line 52: Including file /etc/ssh/ssh_config.d/05-redhat.conf depth 0
debug1: Reading configuration data /etc/ssh/ssh_config.d/05-redhat.conf
debug2: checking match for 'final all' host ip-172-31-14-154 originally ip-172-31-14-154
debug3: /etc/ssh/ssh_config.d/05-redhat.conf line 3: not matched 'final'
debug2: match not found
debug3: /etc/ssh/ssh_config.d/05-redhat.conf line 5: Including file /etc/crypto-policies/back-ends/openssh.config depth 1 (parse only)
debug1: Reading configuration data /etc/crypto-policies/back-ends/openssh.config
debug3: gss kex names ok: [gss-curve25519-sha256-,gss-nistp256-sha256-,gss-group14-sha256-,gss-group16-sha512-,gss-gex-sha1-,gss-group14-sha1-]
debug3: kex names ok: [curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1]
debug1: configuration requests final Match pass
debug1: re-parsing configuration
debug1: Reading configuration data /etc/ssh/ssh_config
debug3: /etc/ssh/ssh_config line 52: Including file /etc/ssh/ssh_config.d/05-redhat.conf depth 0
debug1: Reading configuration data /etc/ssh/ssh_config.d/05-redhat.conf
debug2: checking match for 'final all' host ip-172-31-14-154 originally ip-172-31-14-154
debug3: /etc/ssh/ssh_config.d/05-redhat.conf line 3: matched 'final'
debug2: match found
debug3: /etc/ssh/ssh_config.d/05-redhat.conf line 5: Including file /etc/crypto-policies/back-ends/openssh.config depth 1
debug1: Reading configuration data /etc/crypto-policies/back-ends/openssh.config
debug3: gss kex names ok: [gss-curve25519-sha256-,gss-nistp256-sha256-,gss-group14-sha256-,gss-group16-sha512-,gss-gex-sha1-,gss-group14-sha1-]
debug3: kex names ok: [curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1]
debug2: resolving "ip-172-31-14-154" port 22
debug2: ssh_connect_direct
debug1: Connecting to ip-172-31-14-154 [172.31.14.154] port 22.
debug1: Connection established.
debug1: identity file /home/source/.ssh/id_rsa type 0
debug1: identity file /home/source/.ssh/id_rsa-cert type -1
debug1: identity file /home/source/.ssh/id_dsa type -1
debug1: identity file /home/source/.ssh/id_dsa-cert type -1
debug1: identity file /home/source/.ssh/id_ecdsa type -1
debug1: identity file /home/source/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/source/.ssh/id_ed25519 type -1
debug1: identity file /home/source/.ssh/id_ed25519-cert type -1
debug1: identity file /home/source/.ssh/id_xmss type -1
debug1: identity file /home/source/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.0
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.0
debug1: match: OpenSSH_8.0 pat OpenSSH* compat 0x04000000
debug2: fd 4 setting O_NONBLOCK
debug1: Authenticating to ip-172-31-14-154:22 as 'destination'
debug3: hostkeys_foreach: reading file "/home/source/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /home/source/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys from ip-172-31-14-154
debug3: order_hostkeyalgs: prefer hostkeyalgs: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
debug3: receive packet: type 20
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,ext-info-c
debug2: host key algorithms: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519-cert-v01@openssh.com,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug2: ciphers ctos: aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes256-ctr,aes256-cbc,aes128-gcm@openssh.com,aes128-ctr,aes128-cbc
debug2: ciphers stoc: aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes256-ctr,aes256-cbc,aes128-gcm@openssh.com,aes128-ctr,aes128-cbc
debug2: MACs ctos: hmac-sha2-256-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha2-256,hmac-sha1,umac-128@openssh.com,hmac-sha2-512
debug2: MACs stoc: hmac-sha2-256-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha2-256,hmac-sha1,umac-128@openssh.com,hmac-sha2-512
debug2: compression ctos: none,zlib@openssh.com,zlib
debug2: compression stoc: none,zlib@openssh.com,zlib
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1
debug2: host key algorithms: rsa-sha2-512,rsa-sha2-256,ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519
debug2: ciphers ctos: aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes256-ctr,aes256-cbc,aes128-gcm@openssh.com,aes128-ctr,aes128-cbc
debug2: ciphers stoc: aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes256-ctr,aes256-cbc,aes128-gcm@openssh.com,aes128-ctr,aes128-cbc
debug2: MACs ctos: hmac-sha2-256-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha2-256,hmac-sha1,umac-128@openssh.com,hmac-sha2-512
debug2: MACs stoc: hmac-sha2-256-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha2-256,hmac-sha1,umac-128@openssh.com,hmac-sha2-512
debug2: compression ctos: none,zlib@openssh.com
debug2: compression stoc: none,zlib@openssh.com
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: aes256-gcm@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: aes256-gcm@openssh.com MAC: <implicit> compression: none
debug1: kex: curve25519-sha256 need=32 dh_need=32
debug1: kex: curve25519-sha256 need=32 dh_need=32
debug3: send packet: type 30
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug3: receive packet: type 31
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:bASX/U9HJi3iu0CUsUY+VcYlZR4mE8/b1tJQcl69RpM
debug3: hostkeys_foreach: reading file "/home/source/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /home/source/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys from ip-172-31-14-154
debug3: hostkeys_foreach: reading file "/home/source/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /home/source/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys from 172.31.14.154
debug1: Host 'ip-172-31-14-154' is known and matches the ECDSA host key.
debug1: Found key in /home/source/.ssh/known_hosts:1
debug3: send packet: type 21
debug2: set_newkeys: mode 1
debug1: rekey out after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: receive packet: type 21
debug1: SSH2_MSG_NEWKEYS received
debug2: set_newkeys: mode 0
debug1: rekey in after 4294967296 blocks
debug1: Will attempt key: /home/source/.ssh/id_rsa RSA SHA256:jtcQnDlr00yb91sOVgNn4dH4Gj0cqu79GJ2pZ+Kv3mA
debug1: Will attempt key: /home/source/.ssh/id_dsa
debug1: Will attempt key: /home/source/.ssh/id_ecdsa
debug1: Will attempt key: /home/source/.ssh/id_ed25519
debug1: Will attempt key: /home/source/.ssh/id_xmss
debug2: pubkey_prepare: done
debug3: send packet: type 5
debug3: receive packet: type 7
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-keyex,gssapi-with-mic,password
debug3: preferred gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup gssapi-with-mic
debug3: remaining preferred: publickey,keyboard-interactive,password
debug3: authmethod_is_enabled gssapi-with-mic
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure. Minor code may provide more information
No Kerberos credentials available (default cache: KCM:)
debug1: Unspecified GSS failure. Minor code may provide more information
No Kerberos credentials available (default cache: KCM:)
debug2: we did not send a packet, disable method
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /home/source/.ssh/id_rsa RSA SHA256:jtcQnDlr00yb91sOVgNn4dH4Gj0cqu79GJ2pZ+Kv3mA
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Trying private key: /home/source/.ssh/id_dsa
debug3: no such identity: /home/source/.ssh/id_dsa: No such file or directory
debug1: Trying private key: /home/source/.ssh/id_ecdsa
debug3: no such identity: /home/source/.ssh/id_ecdsa: No such file or directory
debug1: Trying private key: /home/source/.ssh/id_ed25519
debug3: no such identity: /home/source/.ssh/id_ed25519: No such file or directory
debug1: Trying private key: /home/source/.ssh/id_xmss
debug3: no such identity: /home/source/.ssh/id_xmss: No such file or directory
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
destination@ip-172-31-14-154's password:
chmod 0600 /home/your_home/.ssh/authorized_keys
After that go to /etc/ssh/sshd_config
PubkeyAuthentication yes
systemctl restart sshd
Source Public key is updated on the destination authorized keys . Now try
destination@ip-172-31-14-154 .ssh]$ cat authorized_keys
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCqLtvCpcoVJi5NmVNEwgf1+RyNvpvVF5iIKGRAZYZZJv18qeOx5Rm+cIhw3xPmqrEDQrxOJmSwC5Z+CRVO0BHNf8uvln1c6ES+4QevfmKgmTFMy5oIpfyr+00AUHEBAvxlb/y0slvg0LvdP/f5S2UW97AkjioHcb0YUUHGchUuCgePKt/HbVlomoTfQdlf7gm2QejynWIADD6KgOHCqxP4rJuYe9sp3nxC/ViwIqSOsGKHi8bCKf1g8OU9M57A4vlwaORnUKZ8v2mJeXUQkkGJI4cfVfv2tS/Y9jETyBjDR4/m46Kb0que08Swe0pMouOJFK4pXMjNLXOLAiCpIwmtzkiq6Q9G5Qw5FDCo6AiFRXv1IQNCDqXcXRDfhMh6C81u969Xpk+uWi6tYOXIV4cib+aIEU295GXOAEcSbJKujhmXuF6FHUUsHeK1+0etaB29XPjbkYvOHdsbnBwspS0tKp+Siba1+HutKn3kuZGn9HJWdVn83zBh8FIjMIKtb69S9P2zgprM1Y/1M+Bo0yRMxZwTY/FPHx0BXrGIGCzR2qhWeNk/w/N1qkG3nUkDFfX4Lh1IvrCQjHuZwH88JBVsSC7MqFoMlfd7D+1f6q+oQ73ARtdCMwEo2irmUbv5rpnFNFn84MdIhk6UlDs8xhjYAOmhfDKTEVyyATjGIN5r3Q== source@ip-172-31-14-154.us-east-2.compute.internal
[destination@ip-172-31-14-154 .ssh]$ ls -lrt
total 12
-rw-r--r--. 1 destination destination 781 May 2 05:05 id_rsa.pub
-rw-------. 1 destination destination 3434 May 2 05:05 id_rsa
-rw-------. 1 destination destination 776 May 2 05:45 authorized_keys
[destination@ip-172-31-14-154 .ssh]$
[source@ip-172-31-14-154 ~]$ ssh destination@ip-172-31-14-154
Last login: Sun May 2 05:45:50 2021 from 172.31.14.154
[destination@ip-172-31-14-154 ~]$
YESSSS Successful after a couple of issues . Now source is able to connect to destination without password . scp also now works without password authentication
Now we can do vice versa . Means upload destination public key [.pub file ] to source and configure in authorized_keys then destination will be able to connect to source without password .Lets do it quickly .
[destination@ip-172-31-14-154 ~]$ ssh source@ip-172-31-14-154
The authenticity of host 'ip-172-31-14-154 (172.31.14.154)' can't be established.
ECDSA key fingerprint is SHA256:bASX/U9HJi3iu0CUsUY+VcYlZR4mE8/b1tJQcl69RpM.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'ip-172-31-14-154,172.31.14.154' (ECDSA) to the list of known hosts.
source@ip-172-31-14-154's password:
Last login: Sun May 2 05:44:10 2021
[source@ip-172-31-14-154 ~]$
[source@ip-172-31-14-154 ~]$
[source@ip-172-31-14-154 ~]$ ls -lrt
total 4
-rw-r--r--. 1 source source 781 May 2 05:54 id_rsa.pub
[source@ip-172-31-14-154 ~]$
[source@ip-172-31-14-154 .ssh]$ ls -lrt
total 20
-rw-r--r--. 1 source source 776 May 2 05:04 id_rsa.pub
-rw-------. 1 source source 3422 May 2 05:04 id_rsa
-rw-r--r--. 1 source source 776 May 2 05:14 destination@localhost
-rw-r--r--. 1 source source 363 May 2 05:15 known_hosts
-rw-rw-r--. 1 source source 781 May 2 05:55 authorized_keys
Finally we are able to connect to both id's vice versa without password . SCP also now can without password authentication .
[source@ip-172-31-14-154 .ssh]$ ssh destination@ip-172-31-14-154
Last login: Sun May 2 05:56:42 2021 from 172.31.14.154
[destination@ip-172-31-14-154 ~]$ ssh source@ip-172-31-14-154
Last login: Sun May 2 05:57:09 2021 from 172.31.14.154
[source@ip-172-31-14-154 ~]$
If SSH Tectia installed then sshg3 instead of ssh and scpg3 instead of scp tools available . rest of the steps remain same .
awk works on programs that contain rules comprised of patterns and actions. The action is executed on the text that matches the pattern. Patterns are enclosed in curly braces ({}). Together, a pattern and an action form a rule. The entire awk program is enclosed in single quotes (').
Here is the output of -h
Perhaps i don’t need all the output I want only mounted file systems to print and it size let say.
In the above we are ignoring first description line using grep –v. Then printing required values .Infact we can print as many values as we want . NF holds last values .
$0 represents entire line
$1 represents the first field
$2 represent second field
$7 represent 7th field
$NF represents the last record.
In the previous command if we don’t specify delimiter then space is the default . so df –h delimited with space then we are printing the values.Also we used “ “ space when printing .If we use , then space used while printing.
Another example just want to print the date in Mon DD YYYY format
date | awk '{print $2,$3,$6}'
OFS --> Output field Separator
date | awk 'OFS="-" {print$2,$3,$6}'
The BEGIN and END Rules
A BEGIN rule is executed once before any text processing starts. In fact, it’s executed before awk even reads any text. An END rule is executed after all processing has completed. You can have multiple BEGIN and END rules, and they’ll execute in order.
We can also add patterns before printing with AWK . In the below example we will check if the 3rd value greater or equal 1000 the print those rows or fields on those rows .
Combining both BEGIN and patterns on awk
In case if we want to develop our own logic using awk follow below
The first line of the script tells the shell which executable to use
#!/usr/bin/awk -f
BEGIN {
# set the input and output field separators
FS=":"
OFS=":"
# zero the accounts counter
accounts=0
}
{
# set field 2 to nothing
$2=""
# print the entire line
print $0
# count another account
accounts++
}
END {
# print the results
print accounts " accounts.\n"
}
Hope this article help to use awk for data processing with advance utility ...
Follow below steps to get SSL certificate for an JAVA based Application server .In the below steps we will use keytool which is availale in JAVA_HOME/bin/
Create a new keystore keystore.jks for managing your public/private key pairs and certificates.
Note : -v option is for detailed output
Keytool help for the commands
[wlsuser@localhost tmp]$ keytool
Key and Certificate Management Tool
Commands:
-certreq Generates a certificate request
-changealias Changes an entry's alias
-delete Deletes an entry
-exportcert Exports certificate
-genkeypair Generates a key pair
-genseckey Generates a secret key
-gencert Generates certificate from a certificate request
-importcert Imports a certificate or a certificate chain
-importpass Imports a password
-importkeystore Imports one or all entries from another keystore
-keypasswd Changes the key password of an entry
-list Lists entries in a keystore
-printcert Prints the content of a certificate
-printcertreq Prints the content of a certificate request
-printcrl Prints the content of a CRL file
-storepasswd Changes the store password of a keystore
Use "keytool -command_name -help" for usage of command_name
[wlsuser@localhost tmp]$
Generate a CSR in the file carequest.csr for submission to a CA. The CA signs and returns a certificate or a certificate chain that authenticates your public key.
CSR
keytool -certreq -v -alias mycert -file carequest.csr -keystore keystore.jks -storepass storepassword
Send or upload the csr file to the third pary site like and get it signed . Then download root ,intermediate certificates and carequest.cer file .
Print the contents of a certificate file in a human-readable form.
keytool -printcert -v -file carequest.cer
Delete the certificate with the alias aliasname from the keystore keystore.jks.
keytool -delete -alias aliasname -keystore keystore.jks -storepass storepassword
print the certificate
keytool -printcert -f mycert.cer
Now the keystore is ready. we can use this keystore to configure in Application server's like Jboss,Weblogic,Websphere,tomcat ..etc
In a certificate if both Owner and Issuer are same then it is Self signed certificate . We can use self signed cert for the server but it is not secured and not recommended. Every root certificate of the Third party provider are self signed it self and used to sign other certificates .
If we have any SSL handshake issue first we need to understand the details steps that take place during SSL handshake then only we will be able to address it easily . Find the below some of the details .
There are multiple reasons for SSL handshake . When we get this Error on the logs . First of all we need to verify server side whether the SSL configured is 2 Ways SSL or 1 Way SSL .
SSL Handshake Issue troubleshooting :
Make sure the Public keys [ Trusted certificates (root & Intermediate )] are imported in the client truststore .
For 2 Ways SSL both side Signer certificate should be imported .
If Server side enforce the certificate then server certificate also need to import at the client trust store .
Both side should have at-least a common Allowed Protocol . Ex TLS1.2 and a cipher
If something is not satisfied in the above then make the changes accordingly .Like importing the signers in to truststore
keytool -import -file /tmp/root.cer -alias root -keysoore /pathToSSL/***.jks then enter and provide the password .
In some case we can not figure out what is the issue .Then enable SSL debug using below parameter in startup script or in the server JVM arguement .then restart the JVM
-Djavax.net.debug=ssl:handshake:verbose
once restarted test the connectivity . In the logs we can see full debug statements . and also we can see what trusted certs are loaded .There are certain steps in SSL handshake all are printed . Refer below table for SSL Handshake to get better idea .
In the above error handshake failed because Server side rejectClientNegotiation is set to true . and client tried to negotiate for multiple call's renegotiation_info that is where it failed .
Now you can match every step in the SSL handshake debug log with the attached screen to see at what step the failure happened .
Websphere Application server failed to start after Applying 8.5.5.18 patch . From the logs i see below error .
[11/21/20 20:32:17:992 GMT+08:00] 00000001 SSLComponentI A CWPKI0007I: SSL service failed to start successfully
[11/21/20 20:32:17:994 GMT+08:00] 00000001 WsServerImpl E WSVR0100W: An error occurred initializing, server1 [class com.ibm.ws.runtime.component.ServerImpl]
com.ibm.ws.exception.ConfigurationError: com.ibm.websphere.ssl.SSLException: java.lang.NullPointerException
at com.ibm.ws.ssl.core.SSLComponentImpl.initialize(SSLComponentImpl.java:208)
...
Caused by: java.lang.NullPointerException
at com.ibm.ws.ssl.config.WSKeyStore$1.run(WSKeyStore.java:745)
at com.ibm.ws.security.util.AccessController.doPrivileged(AccessController.java:118)
at com.ibm.ws.ssl.config.WSKeyStore.do_getKeyStore(WSKeyStore.java:645)
at com.ibm.ws.ssl.config.WSKeyStore.getKeyStore(WSKeyStore.java:911)
at com.ibm.ws.ssl.config.WSKeyStore.initializeKeyStore(WSKeyStore.java:1098)
at com.ibm.ws.ssl.config.SSLConfigManager.parseSecureSocketLayer1(SSLConfigManager.java:1191)
at com.ibm.ws.ssl.config.SSLConfigManager.parseSSLConfig(SSLConfigManager.java:751)
at com.ibm.ws.ssl.config.SSLConfigManager.initializeServerSSL(SSLConfigManager.java:302)
FFDC:
[11/21/20 20:32:17:937 GMT+08:00] FFDC Exception:java.lang.NullPointerException SourceId:com.ibm.ws.ssl.core.SSLConfigManager.initializeServerSSL ProbeId:312 Reporter:com.ibm.ws.ssl.config.SSLConfigManager@6e37fe8a
java.lang.NullPointerException
at com.ibm.ws.ssl.config.WSKeyStore$1.run(WSKeyStore.java:745)
at com.ibm.ws.security.util.AccessController.doPrivileged(AccessController.java:118)
at com.ibm.ws.ssl.config.WSKeyStore.do_getKeyStore(WSKeyStore.java:645)
at com.ibm.ws.ssl.config.WSKeyStore.getKeyStore(WSKeyStore.java:911)
at com.ibm.ws.ssl.config.WSKeyStore.initializeKeyStore(WSKeyStore.java:1098)
at com.ibm.ws.ssl.config.SSLConfigManager.parseSecureSocketLayer1(SSLConfigManager.java:1191)
at com.ibm.ws.ssl.config.SSLConfigManager.parseSSLConfig(SSLConfigManager.java:751)
at com.ibm.ws.ssl.config.SSLConfigManager.initializeServerSSL(SSLConfigManager.java:302)
at com.ibm.ws.ssl.core.SSLComponentImpl.initialize(SSLComponentImpl.java:145)
.
So something related to your security settings..
This error occurs on the environment where custom password jar is used . and there is are testfixes available .Just like add JVM arguements
The client channel definition table (CCDT) determines the channel definitions and authentication information used by client applications to connect to the queue manager.
Ex:It has channel name ,ConnName ,QMGRName,cipher … etc
The purpose of the client channel definition table (CCDT) is to determine the channel definitions used by client applications to connect to the queue manager. The channel definition also specifies the authentication information that applies to the connections. The CCDT is a binary file. It is generated by a queue manager. The queue manager does not read the CCDT file.
There are a number of ways for a client application to use a CCDT. The CCDT can be copied to the client computer. You can copy the CCDT to a location shared by more than one client. You can make the CCDT accessible to the client as a shared file, while it remains located on the server.
If you use FTP to copy the file, use the bin option to set binary mode; do not use the default ASCII mode. Whichever method you choose to make the CCDT available, the location must be secure to prevent unauthorized changes to the channels.
The CCDT is created when the queue manager is created. Each entry of a CCDT represents a client connection to a specific queue manager. A new entry is added when you define a client-connection channel using the DEFINE CHANNEL command, and the entry is updated when you alter the client-connection channels by using the ALTER CHANNEL command.
The path to the CCDT can be changed by setting MQCHLLIB. If you do set MQCHLLIB, be aware, if you have multiple queue managers on the same server, they share the same CCDT location.
On Linux/AIX
/var/mqm/qmgrs/QUEUEMANAGERNAME/@ipcc
On Windows
MQ_INSTALLATION_PATH\data\qmgrs\QUEUEMANAGERNAME\@ipcc
MQCHLTAB specifies the name of the file containing the client channel definition table (ccdt). The default file name is AMQCLCHL.TAB.
On Windows:
SET MQCHLTAB=filenameCopy code
On UNIX and Linux® systems:
export MQCHLTAB=filename
Let us create a chaneel tab file for the below connection from QMGR
[mqm@ip-172-31-14-154 ~]$ runmqsc APPQM1
5724-H72 (C) Copyright IBM Corp. 1994, 2020.
Starting MQSC for queue manager APPQM1.
DEFINE CHANNEL(CL.APPQM1) CHLTYPE(CLNTCONN) TRPTYPE(TCP) CONNAME('172.31.14.154(1417)') QMNAME(APPQM1)
1 : DEFINE CHANNEL(CL.APPQM1) CHLTYPE(CLNTCONN) TRPTYPE(TCP) CONNAME('172.31.14.154(1417)') QMNAME(APPQM1)
AMQ8014I: IBM MQ channel created.
DEFINE CHANNEL(CL.APPQM1) CHLTYPE(SVRCONN) TRPTYPE(TCP)
2 : DEFINE CHANNEL(CL.APPQM1) CHLTYPE(SVRCONN) TRPTYPE(TCP)
AMQ8014I: IBM MQ channel created.
end
3 : end
2 MQSC commands read.
No commands have a syntax error.
All valid MQSC commands were processed.
[mqm@ip-172-31-14-154 ~]$
AMCLCHL.TAB file is a binary file . If we view we can see connection information but cannot read complete file .
Now if i want to create another Channel tab from the same QMGR with different channel then it is difficult because this file will be modified or updated with all the channel information from the QMGR .
From the Latest version onwards we have an easy way to generate Channel Tab using runmsc -n command . By default runmqsc -n Look for the channle tab in /var/mqm . If we run this command then it will read the file from that location if exist otherwise it will create new so that we can update the definitons of channels that we intended to create for Application connectivity .
Note: We only need SVRCONN on QMGR Side . CLNTCONN is only need for Application that used CHLTAB file . so we will define only CLNTCONN on channel tab file .
[mqm@ip-172-31-14-154 @ipcc]$ cd /var/mqm
[mqm@ip-172-31-14-154 ~]$ ls -lrt
total 24
drwxrwsr-x. 3 mqm mqm 19 Dec 29 15:56 conv
drwxrwsr-x. 2 mqm mqm 6 Dec 29 15:56 config
drwxrwsr-x. 3 mqm mqm 27 Dec 29 15:56 web
drwxrwsrwx. 2 mqm mqm 6 Dec 29 15:56 trace
-rw-rw-r--. 1 mqm mqm 1941 Dec 29 15:56 service.env
drwxrwsr-x. 5 mqm mqm 53 Dec 29 15:56 mqft
drwxrwsr-x. 4 mqm mqm 32 Dec 29 15:56 shared
-rw-rw-r--. 1 mqm mqm 661 Dec 29 15:56 mqclient.ini
drwxrwsr-x. 3 mqm mqm 27 Dec 29 15:56 exits
drwxrwsr-x. 3 mqm mqm 27 Dec 29 15:56 exits64
drwxrwsr-x. 15 mqm mqm 177 Jan 4 11:44 sockets
drwxrwsr-x. 15 mqm mqm 177 Jan 4 11:44 qmgrs
-rw-rw-r--. 1 mqm mqm 3674 Jan 4 11:44 mqs.ini
drwxrwsr-x. 14 mqm mqm 162 Jan 4 11:44 log
drwxrwsrwx. 2 mqm mqm 8192 Jan 9 07:06 errors
[mqm@ip-172-31-14-154 ~]$
[mqm@ip-172-31-14-154 ~]$ runmqsc -n
5724-H72 (C) Copyright IBM Corp. 1994, 2020.
Starting local MQSC for 'AMQCLCHL.TAB'.
dis chl(*)
1 : dis chl(*)
AMQ9518E: File '/var/mqm/AMQCLCHL.TAB' not found.
end
2 : end
No commands have a syntax error.
[mqm@ip-172-31-14-154 ~]$
This is when try to read a channel tab if the file diesnot exist . Let's create one .refer below
[mqm@ip-172-31-14-154 ~]$ ls -lrt /var/mqm/AMQCLCHL.TAB
-rw-rw-r--. 1 mqm mqm 2106 Jan 10 05:53 /var/mqm/AMQCLCHL.TAB
[mqm@ip-172-31-14-154 ~]$
If you want to create in different location then we have to set MQCHLLIB.
For Windows:
SET MQCHLLIB=pathname
For UNIX and Linux systems:
export MQCHLLIB=pathname
Migration and client channel definition tables (CCDT) In general, the internal format of the client channel definition table might change from one release level of IBM WebSphere MQ to the next. As a result, an IBM WebSphere MQ MQI client can use a client channel definition table only when it has been prepared by a server queue manager that is at the same release level as the client, or at an earlier release level.
If we generate a CHLTAB and try to use in Older version of client it may not work . Take the working TAB file and edit using runmqsc -n then modify then it should work fine .
