One smart card reader accessible from many computers

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 use.


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.

Multi-architecture support

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.

The internal pcsc-lite protocol is not sensible to 32 or 64-bits CPU differences. I have not tested a mix with big-endian and little-endian CPUs. I do not have a computer using a big-endian CPU. I am pretty sure that configuration would fail.


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.