ssh-rsa being deprecated


Announced 2020-05-27 on http://www.openssh.com/releasenotes.html
This is about ssh client authenticates server, not the other way.
This is not about the server’s public key itself, but the hash of it, which only matters when being added to known_hosts.

Here I talk about two ways of ssh in: the default way, and the deprecated way.
Here are the public keys on my server:
rio@u:/etc/ssh$ ls *.pub
ssh_host_dsa_key.pub ssh_host_ecdsa_key.pub ssh_host_ed25519_key.pub ssh_host_rsa_key.pub
rio@u:/etc/ssh$ lsb_release -d
Description: Ubuntu 14.04.5 LTS

The default way:
$ ssh -V output: OpenSSH_7.6p1 Ubuntu-4, OpenSSL 1.0.2n 7 Dec 2017
$ ssh -vvv -F config u
output: ECDSA key fingerprint is 70:97…
by $ ssh-keygen -l -f ssh_host_ecdsa_key.pub, we see this finger print is 256 MD5:70:97…
Therefore the default login is: ECDSA + md5


The deprecated way:
$ ssh -vvv -o HostKeyAlgorithms=ssh-rsa -o FingerprintHash=sha1 -F config u
output: RSA key fingerprint is SHA1:lWDfeoWl4nGcMNCAL81PA6YT4jc.
by $ ssh-keygen -l -E sha1 -f ssh_host_rsa_key.pub, we see this finger print is2048 SHA1:lWDf…
Therefore the login is: RSA + SHA1

I inspected all my severs, including Ubuntu 14 and Cent 7, and they all support ECDSA.
Therefore, not affected by this release note.

eval in bash


Sometimes there is an alternative to eval, sometimes not.
When there is an alternative: indirect expansion
eval echo \${$VARVAR} can be replaced by echo ${!VARVAR}

When there is no alternative, as far as I know:
To do quoting, escaping, redirection, piping after parameter expansion, as seen in the two cases below.
1. $ book=”\”This Book.pdf\”” ; eval rm $book
2. $CMD=”echo SeeingMeAlongMeansSuccess |cat” ; eval $CMD
Without eval, we cannot prevent |cat from being passed to execve(2) system call, which is not what we want

Download has detailed demo and explanation.
http://riowing.net/p/evalmy.sh

Mount google drive on headless Ubuntu


On remote google side:
This application need to get permission from Google to access the Drive API (not to be confused with access to a certain user’s Drive)
In order to identify the application, I apply a ClientID, pretending I present this application, RioGdFuse, to Google.
Create OAuth2 credentials: ClientID and ClientSecret, for google to authenticate the application
Go to: https://console.cloud.google.com/apis/credentials with account RioWng@gmail.com as developer account
Enable Drive API: This is for the developer account RioWng
Go to: https://console.cloud.google.com/apis/library

On local, ubuntu side:
Install google-drive-ocamlfuse
add-apt-repository ppa:alessandro-strada/ppa; apt-get update
apt-get install google-drive-ocamlfuse
google-drive-ocamlfuse -headless -label dRioChn -id $ClientID -secret $ClientSecret
Get token:
$ google-drive-ocamlfuse -headless -label dRioCn -id $ClientID -secret $ClientSecret
RioCn is a label to identify the Dirve that will be accessed, like RioCn@gmail.com, when multiple Drive accessed
Replace ClientID ClientSecret with your strings.
This command prints a URL, which be pasted to browser. then sign in with the accessed Drive account, like RioCn, and get back verification code.
Basically this URL send the client ID to Google, and the verification code tells the application RioGdFuse is granted access to RioCn Drive.
This URL looks like https://accounts.google.com/o/oauth2/auth?client_id=372… Verificaton code looks like 4/zgGst…
Config result and logs are in folder: ~/.gdfuse/dRioCn
Mount the drive:
$ google-drive-ocamlfuse -debug -label dRioChn /mnt/ebs/rio/proj/gdrive/mt
Try it out:
$ cd /mnt/ebs/rio/proj/gdrive/mt
$ ls this lists, e.g. Contact.xml, which was created 10 years ago on the Drive. see Screenshot

Notes:
When mounting, google-drive-ocamlfuse doesn’t exit, therefore no message like “mount success”.
The meaning for error messages do not appear until operating the mount point, e.g. $ls mt
The API is very slow, in addition, it processes file one after another.
WSL1 doesn’t work as it doesn’t support FUSE

Reference: https://github.com/astrada/google-drive-ocamlfuse/wiki/Headless-Usage-&-Authorization

gdFuseResult

Wireless Display


1. WiDi
WiDi is Miracast-compatible.
Miracast is not strict, and has other brands/implementations like:
LG SmartShare, Samsung AllShare Cast, Sony Screen Mirroring and Panasonic Display Mirroring.
I see it as forwarding the whole video buffer, including the controls/HUD of course.
I tested Windows 10 cast to another Windows 10 and Roku Player. see Miracast.jpg

2. Chromecast uses DIAL standard: DIscovery And Launch
Instead of forwarding video buffer, it sends the video content and launches an application on the target to play it.
Therefore it has more flexibility, e.g. showing the video but no play/pause button
I tested it with Nexus Android 7 casting to Chromecast stick connected to TV and Google home Mini. see Dial.jpg

3. AirPlay also launches applcation on destination, and is Apple proprietary.