ssh-rsa being deprecated

Announced 2020-05-27 on
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
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, 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, 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.

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: with account as developer account
Enable Drive API: This is for the developer account RioWng
Go to:

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, 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… 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

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



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.