Forum Replies Created
-
Posts
-
Thats not the right machine . We want the output from 00954b21-57cf-40e2-86c2-0d7b7269fecb-classifier node
Can you please post the output of
ls -lad /home/ubuntuls -la /home/ubuntu/.ssh
The can see from the ssh log that the ownership of home directory is the issue
Dec 02 18:07:16 00954b21-57cf-40e2-86c2-0d7b7269fecb-classifier sshd[60744]: Connection closed by authenticating user ubuntu 2001:400:a100:1030::51 port 52118 [preauth]
Dec 02 18:07:16 00954b21-57cf-40e2-86c2-0d7b7269fecb-classifier sshd[60744]: Authentication refused: bad ownership or modes for directory /home/ubuntu
Dec 02 18:07:09 00954b21-57cf-40e2-86c2-0d7b7269fecb-classifier sshd[60742]: Connection closed by authenticating user ubuntu 2001:400:a100:1030::51 port 52104 [preauth]
Dec 02 18:07:09 00954b21-57cf-40e2-86c2-0d7b7269fecb-classifier sshd[60742]: Authentication refused: bad ownership or modes for directory /home/ubuntu
Dec 02 18:06:35 00954b21-57cf-40e2-86c2-0d7b7269fecb-classifier sshd[60740]: Connection closed by authenticating user ubuntu 2001:400:a100:1030::51 port 50056 [preauth]
Dec 02 18:06:35 00954b21-57cf-40e2-86c2-0d7b7269fecb-classifier sshd[60740]: Authentication refused: bad ownership or modes for directory /home/ubuntuCan you please grab the logs using
sudo journalctl -r -u ssh >/tmp/ssh.log
and then email help@fabric-testbed.net with the ssh.log file attached .If pullout the file is not possible then just run
sudo journalctl -r -u ssh
and copy the few recent lines that will help us debug the issue.
I have a anotehr notebook in the same foler that show creating a site. The notebooks picks random sites using a filter that asks for PTP capable only. Here’s the relevant line
sites = fablib.get_random_sites(count=4,filter_function=lambda x:x['ptp_capable'] is True, avoid=(avoid_sites)) https://github.com/fabric-testbed/jupyter-examples/blob/main/fabric_examples/public_demos/KNIT7/Tutorial1_Precision_Time_Measurements_in_FABRIC/knit7_create_topology.ipynb
I would also like to mention that we do not use chrony in our PTP setup. We instead use a utility called phc2sys . There are other utilities in the linuxptp package that let you ask for timestamps and report accuracy.
If you like to use chrony for this purpose, let me know and i can provide you instructions to disable the phc2sys and use chrony with the PTP device as a syncronization source.
okay . So since nothing is being used, all you are doing is running NTP against the default timeservers that chrony picks up. So even if your second VM may be on the same rack, you will achive the accuracy that NTP provides.
Network Time Protocol (NTP) can achieve accuracy <mark class=”QVRyCf”>within tens of milliseconds over the internet, and within one millisecond in local area networks (LANs) under ideal conditions</mark>. However, accuracy can be affected by several factors, including:- Network congestion and asymmetric routes: These can cause errors of 100 milliseconds or more.
- Stratum: The higher the stratum number, the lower the accuracy. Stratum 0 devices, such as atomic and GPS clocks, are the most accurate, but they can’t be connected to via a network connection.
- Physical distance: The further the synchronizing server is from the client, the lower the accuracy
If you would like more achive more accurate measurements you can use PTP. We do have a notebook that you can use to setup PTP in your slice which would allow you to synchronize the system clocks on your VMs.
Just make sure the sites you use have the PTP capability as not all FABRIC sites use PTP.
This notbeook show how to setup PTP synchronization on your VMs. https://github.com/fabric-testbed/jupyter-examples/blob/main/fabric_examples/public_demos/KNIT7/Tutorial1_Precision_Time_Measurements_in_FABRIC/knit7_install_PTP.ipynb
Once setup, all the system clocks on all the VMs in the slice should be in sync to the order of 10s of microseconds or better
Thats it right there. Slice keys are not automatically updated into your VMs. You hae to run a notebook to get FABRIC to push the updated slice keys to your nodes. There is a sample notebook in the jupyter_examples/fabric_examples/fablib_api/ssh_keys/ thats show the needed commands for this.
Looks like that worked at the bastion. Time to check your slice key. This is the firngerprint of the key on the VM you are trying to connect to. Please compare it with the one you are using.
SHA256:wKS8vx7URNxBun4O+oWkyUq+SPxb9HbKFgH782mh0B8
Can you please try this one more time with the verbose output. New keys are pushed out on a time interval basis. Your latest key was updated in the bastion just 2 mins ago.
Sure you can do that, but its a ssh config issue/wrong key issue, then it may not resolve the issue. GO ahead and no the new key.
Looking at the authentication logs from the bastion, your machine is present the wrong ssh key to authenticate at the bastion. From our logs the fingerprint for the key you are using is
SHA256:Oz6TG1SqPn3WXDeMmkkO+aj4sLqqgXCjScfLKc0LB2k
Where as the key registered for your account uses
SHA256:O2vzi6TM/5gF2pQaZw6IQbAD/iZt9zkkfJW8fvDlPcA (which is the SHA256 equivalent of the fingerprint you mentioned.)
So the ssh key you have is right, but what is being used by ssh is not this correct one. Please check you ssh using a -vvv to grab a verbose log of the failed attempt. That may tell us whats going on.
- Network congestion and asymmetric routes: These can cause errors of 100 milliseconds or more.
