In 2010 I wrote the article "PC/SC client and server on two different hosts". At that time OpenSSH was not able to redirect Unix sockets.
I just received a request to (re)do something similar. Of course, I forgot I wrote this article 12 years ago. So I started searching for a solution, again.
Since OpenSSH 6.7 (released in 2014) it is possible to redirect Unix sockets over the network.
The normal pcsc-lite use case is described in the figure bellow:
The goal is to have 2 computers connected by a network and transfer the pcsc-lite internal connection over the network as described bellow:
On computer1 you have your smart card reader(s) connected and pcscd will run
as usual. You do not need to change your pcsc-lite configuration.
A user on computer1 is able to connect to computer2 using ssh and run something like:
$ ssh -N -R/tmp/pcscd.comm:/run/pcscd/pcscd.comm computer2
Note that the socket on computer2 is /tmp/pcscd.comm and not /run/pcscd/pcscd.comm as on computer1. That is because of access rights restriction. Only root is allowed to create files in /run/pcscd/.
Otherwise I get the error:
Warning: remote port forwarding failed for listen path /run/pcscd/pcscd.comm
So I create the socket on computer2 in /tmp/ instead.
On computer2 you define the pcsc-lite socket path to use.
$ export PCSCLITE_CSOCK_NAME=/tmp/pcscd.comm
And you can run your PC/SC application as usual.
Connection in the other direction
It is also possible to do the SSH connection from the client to the server. On the client you do something like
$ ssh -N -L/tmp/pcscd.comm:/run/pcscd/pcscd.comm computer1
It may be easier this way if the client is light terminal and does not have an
ssh server running for example.
Socket access rights
The socket /tmp/pcscd.comm is created as the user running the ssh command. For example in my case it is created as user "rousseau".
$ ls -l /tmp/pcscd.comm srw------- 1 rousseau rousseau 0 17 févr. 12:07 /tmp/pcscd.comm
As you can see the access rights are limited to read & write for "rousseau" and no access for the other users. You may want to share the remote connection to other users in the client computer. You can do something like:
$ chmod a+rw /tmp/pcscd.comm
The administrator of the system is free to configure the access rights to
When you stop the ssh execution, the socket /tmp/pcscd.comm created on the client side is not removed.
So if you run ssh again you will get the error:
$ ssh -N -R/tmp/pcscd.comm:/run/pcscd/pcscd.comm computer2 Warning: remote port forwarding failed for listen path /tmp/pcscd.comm
or (if the connection is used in the other direction):
$ ssh -N -L/tmp/pcscd.comm:/run/pcscd/pcscd.comm computer1 unix_listener: cannot bind to path /tmp/pcscd.comm: Address already in use Could not request local forwarding.
One card, multiple computers
The same smart card can also be accessed from different computers. The ssh redirection is not limited to one computer. You can have 1 server and 10 clients all connected to the same server so connected to the same smart card reader(s).
The pcsc-lite daemon pcscd will still play his role of resource manager. So if the applications are correctly written with PC/SC transactions to get exclusive access to the card, no problem is expected. i.e. no more problems than if the 3 applications were all running locally in computer1.
It is possible to run the server on one CPU architecture and run clients on a different CPU architecture.
I tried running the server on a x86-64 CPU (Intel PC) and the client on a
ARM-32 CPU (Raspberry Pi 3 using armv7l). It works like a charm.
This architecture is a generalisation of accessing the pcscd server from the host and also from guests in virtual environments (described in "Accessing smart cards from inside a flatpak sandbox") but, this time, with remote computers.
I am sure people will find many original use cases for an architecture like
this. Please tell me if and how you use it.