https://wiki.archlinux.org/api.php?action=feedcontributions&user=Hardfalcon&feedformat=atomArchWiki - User contributions [en]2024-03-28T23:58:58ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Chrony&diff=650593Chrony2021-02-03T00:57:27Z<p>Hardfalcon: /* Usage */ Added section "Checking configured NTP servers"</p>
<hr />
<div>{{Lowercase title}}<br />
[[Category:Network Time Protocol]]<br />
[[ja:Chrony]]<br />
This article describes how to set up and run [http://chrony.tuxfamily.org/ chrony], an alternative [[Time_synchronization|NTP]] client and server that is roaming friendly and designed specifically for systems that are not online all the time.<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|chrony}} package.<br />
<br />
== Configuration ==<br />
<br />
The smallest useful configuration file (using IP addresses instead of a hostname) would look something like: <br />
<br />
{{hc|/etc/chrony.conf|<br />
server 1.2.3.4 offline<br />
server 5.6.7.8 offline<br />
server 9.10.11.12 offline<br />
driftfile /etc/chrony.drift<br />
rtconutc<br />
rtcsync<br />
}}<br />
<br />
=== NTP Servers ===<br />
<br />
The first thing you define in your {{ic|/etc/chrony.conf}} is the servers your machine will synchronize to.<br />
NTP servers are classified in a hierarchical system with many levels called ''strata'': the devices which are considered independent time sources are classified as ''stratum 0'' sources; the servers directly connected to ''stratum 0'' devices are classified as ''stratum 1'' sources; servers connected to ''stratum 1'' sources are then classified as ''stratum 2'' sources and so on.<br />
<br />
It has to be understood that a server's stratum cannot be taken as an indication of its accuracy or reliability. Typically, stratum 2 servers are used for general synchronization purposes: if you do not already know the servers you are going to connect to, you should use the [http://www.pool.ntp.org/ pool.ntp.org] servers ([http://support.ntp.org/bin/view/Servers/NTPPoolServers alternate link]) and choose the server pool that is closest to your location.<br />
<br />
The following lines are just an example:<br />
<br />
server 0.pool.ntp.org iburst<br />
server 1.pool.ntp.org iburst<br />
server 2.pool.ntp.org iburst<br />
server 3.pool.ntp.org iburst<br />
<br />
If your computer is not connected to the internet on startup, it is recommended to use the ''offline'' option, to tell Chrony not to try and connect to the servers, until it has been given the go:<br />
<br />
server 0.pool.ntp.org offline<br />
server 1.pool.ntp.org offline<br />
server 2.pool.ntp.org offline<br />
server 3.pool.ntp.org offline<br />
<br />
It may also be a good idea to either use IP addresses instead of host names, or to map the hostnames to IP addresses in your {{ic|/etc/hosts}} file, as DNS resolving will not be available until you have made a connection.<br />
<br />
==== Using NTS servers ====<br />
<br />
Since version 4.0 [https://git.tuxfamily.org/chrony/chrony.git/tree/NEWS?id=4.0#n6], chrony supports [https://www.rfc-editor.org/rfc/rfc8915.html NTS], a cryptographically secured variety of NTP. To use NTS, you can try the following servers:<br />
<br />
server ptbnts1.ptb.de iburst nts<br />
server ptbnts2.ptb.de iburst nts<br />
server nts.ntp.se iburst nts<br />
server nts.sth1.ntp.se iburst nts<br />
server nts.sth2.ntp.se iburst nts<br />
server time.cloudflare.com iburst nts<br />
<br />
=== Telling chronyd an internet connection has been made ===<br />
<br />
If you are connected to the internet, run:<br />
<br />
{{bc|<br />
# chronyc<br />
chronyc> online<br />
200 OK<br />
chronyc> exit<br />
}}<br />
<br />
You may also be interested in the {{ic|activity}} option to display status:<br />
<br />
{{bc|<br />
# chronyc activity<br />
200 OK<br />
3 sources online<br />
0 sources offline<br />
0 sources doing burst (return to online)<br />
0 sources doing burst (return to offline)<br />
0 sources with unknown address<br />
}}<br />
<br />
Chrony should now connect to the configured time servers and update your clock if needed. To tell chrony that you are not connected to the Internet anymore, execute the following:<br />
<br />
{{bc|<br />
# chronyc offline<br />
200 OK<br />
<br />
# chronyc activity<br />
200 OK<br />
0 sources online<br />
3 sources offline<br />
0 sources doing burst (return to online)<br />
0 sources doing burst (return to offline)<br />
0 sources with unknown address<br />
}}<br />
<br />
The online/offline status can be automatically handled by dispatcher services for {{Pkg|networkmanager}} and {{Pkg|connman}}, see below.<br />
<br />
In conclusion, refer to {{ic|/usr/share/doc/chrony/README}}, which will point you to the right answer to any doubts you could still have. [http://chrony.tuxfamily.org/documentation.html Documentation is also available online.] See also the related man pages: {{ic|man <nowiki>{chronyc|chronyd|chrony.conf}</nowiki>}}).<br />
<br />
<br />
=== For intermittently running desktops ===<br />
<br />
The configuration described here is not really suited well for intermittently running desktops. A machine running Arch Linux for five years, accumulated a 300 s error within the RTC. After a reboot it took chrony a long time to adjust this difference.<br />
<br />
{{hc|/etc/sysconfig/chronyd|output=OPTIONS='-r -s'<br />
}}<br />
<br />
{{hc|/etc/chrony.conf|<br />
dumponexit<br />
dumpdir /var/lib/chrony<br />
rtcfile /var/lib/chrony/rtc<br />
}}<br />
<br />
This keeps, interestingly, the RTC still out-of-date, but after each re-start, chrony adjusts the accumulated error of the RTC and the system time is quite synchronous to NTP even shortly after a start.<br />
<br />
== Usage ==<br />
<br />
=== Starting chronyd ===<br />
<br />
The package provides {{ic|chronyd.service}}, see [[systemd]] for details.<br />
<br />
{{Note| {{ic|systemd-timesyncd.service}} is in conflict with {{ic|chronyd}}, so you need to [[disable]] it first if you want to [[enable]] {{ic|chronyd}} properly.}}<br />
<br />
=== Synchronising chrony hardware clock from the system clock ===<br />
<br />
During boot the initial time is read from the hardware clock (RTC) and the system time is then set, and synchronised over a period of minutes once the chrony daemon has been running for a while. If the hardware clock is out of sync then the initial system time can be some minutes away from the true time. If that is the case it may be necessary to reset the hardware clock.<br />
<br />
You can use chronyc to force the current system time to be synced to hardware:<br />
<br />
{{bc|<br />
# chronyc<br />
chronyc> trimrtc<br />
200 OK<br />
chronyc> quit<br />
}}<br />
<br />
Then exit from chronyc and the RTC and system time should be within a few microseconds of each other and should then be approximately correct on boot and fully synchronise a short time later.<br />
<br />
=== Checking configured NTP servers ===<br />
<br />
To check which NTP servers chrony is actually using, and how precise they are, you can use {{ic|chronyc -N 'sources -a -v'}}:<br />
$ chronyc -N 'sources -a -v'<br />
<br />
.-- Source mode '^' = server, '=' = peer, '#' = local clock.<br />
/ .- Source state '*' = current best, '+' = combined, '-' = not combined,<br />
| / 'x' = may be in error, '~' = too variable, '?' = unusable.<br />
|| .- xxxx [ yyyy ] +/- zzzz<br />
|| Reachability register (octal) -. | xxxx = adjusted offset,<br />
|| Log2(Polling interval) --. | | yyyy = measured offset,<br />
|| \ | | zzzz = estimated error.<br />
|| | | \<br />
MS Name/IP address Stratum Poll Reach LastRx Last sample <br />
===============================================================================<br />
^+ ptbnts1.ptb.de 1 6 377 50 -38us[ -13us] +/- 8723us<br />
^* ptbnts2.ptb.de 1 6 377 49 +2061ns[ +27us] +/- 7538us<br />
^+ nts.ntp.se 2 6 377 51 +594us[ +619us] +/- 15ms<br />
^+ nts.sth1.ntp.se 2 6 377 51 +655us[ +680us] +/- 15ms<br />
^+ nts.sth2.ntp.se 2 6 377 53 +991us[+1016us] +/- 15ms<br />
^+ time.cloudflare.com 3 6 377 49 -1250us[-1250us] +/- 10ms<br />
<br />
== Notifying network state ==<br />
<br />
If you have specified your pools as offline in {{ic|chrony.conf}}, you need to tell ''chrony'' that the network status has changed.<br />
<br />
You can either use ''chronyc'' to notify ''chrony'' that your network configuration has changed, or you can use a dispatcher for your relevant network configuration manager.<br />
<br />
=== NetworkManager ===<br />
<br />
''chronyd'' can go into online/offline mode along with a network connection through the use of [[NetworkManager#Network_services_with_NetworkManager_dispatcher|NetworkManager's dispatcher scripts]]. You can install {{AUR|networkmanager-dispatcher-chrony}} from the AUR.<br />
<br />
=== netctl ===<br />
<br />
Install {{AUR|netctl-dispatcher-chrony}} from the AUR. This adds a hook to netctl which is run automatically for any connection.<br />
<br />
=== dhcpcd ===<br />
<br />
Create the following hook:<br />
<br />
{{hc|/etc/dhcpcd.exit-hook|<br />
if $if_up; then<br />
chronyc online<br />
elif $if_down; then<br />
chronyc offline<br />
fi<br />
}}<br />
<br />
See {{man|8|dhcpcd-run-hooks}}<br />
<br />
== See also ==<br />
<br />
* [[System time]] (for more information on computer timekeeping)<br />
* http://chrony.tuxfamily.org/<br />
* http://www.ntp.org/<br />
* http://support.ntp.org/<br />
* http://www.pool.ntp.org/<br />
* http://www.eecis.udel.edu/~mills/ntp/html/index.html<br />
* http://www.akadia.com/services/ntp_synchronize.html</div>Hardfalconhttps://wiki.archlinux.org/index.php?title=Chrony&diff=650591Chrony2021-02-03T00:48:24Z<p>Hardfalcon: Added section "Using NTS servers"</p>
<hr />
<div>{{Lowercase title}}<br />
[[Category:Network Time Protocol]]<br />
[[ja:Chrony]]<br />
This article describes how to set up and run [http://chrony.tuxfamily.org/ chrony], an alternative [[Time_synchronization|NTP]] client and server that is roaming friendly and designed specifically for systems that are not online all the time.<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|chrony}} package.<br />
<br />
== Configuration ==<br />
<br />
The smallest useful configuration file (using IP addresses instead of a hostname) would look something like: <br />
<br />
{{hc|/etc/chrony.conf|<br />
server 1.2.3.4 offline<br />
server 5.6.7.8 offline<br />
server 9.10.11.12 offline<br />
driftfile /etc/chrony.drift<br />
rtconutc<br />
rtcsync<br />
}}<br />
<br />
=== NTP Servers ===<br />
<br />
The first thing you define in your {{ic|/etc/chrony.conf}} is the servers your machine will synchronize to.<br />
NTP servers are classified in a hierarchical system with many levels called ''strata'': the devices which are considered independent time sources are classified as ''stratum 0'' sources; the servers directly connected to ''stratum 0'' devices are classified as ''stratum 1'' sources; servers connected to ''stratum 1'' sources are then classified as ''stratum 2'' sources and so on.<br />
<br />
It has to be understood that a server's stratum cannot be taken as an indication of its accuracy or reliability. Typically, stratum 2 servers are used for general synchronization purposes: if you do not already know the servers you are going to connect to, you should use the [http://www.pool.ntp.org/ pool.ntp.org] servers ([http://support.ntp.org/bin/view/Servers/NTPPoolServers alternate link]) and choose the server pool that is closest to your location.<br />
<br />
The following lines are just an example:<br />
<br />
server 0.pool.ntp.org iburst<br />
server 1.pool.ntp.org iburst<br />
server 2.pool.ntp.org iburst<br />
server 3.pool.ntp.org iburst<br />
<br />
If your computer is not connected to the internet on startup, it is recommended to use the ''offline'' option, to tell Chrony not to try and connect to the servers, until it has been given the go:<br />
<br />
server 0.pool.ntp.org offline<br />
server 1.pool.ntp.org offline<br />
server 2.pool.ntp.org offline<br />
server 3.pool.ntp.org offline<br />
<br />
It may also be a good idea to either use IP addresses instead of host names, or to map the hostnames to IP addresses in your {{ic|/etc/hosts}} file, as DNS resolving will not be available until you have made a connection.<br />
<br />
==== Using NTS servers ====<br />
<br />
Since version 4.0 [https://git.tuxfamily.org/chrony/chrony.git/tree/NEWS?id=4.0#n6], chrony supports [https://www.rfc-editor.org/rfc/rfc8915.html NTS], a cryptographically secured variety of NTP. To use NTS, you can try the following servers:<br />
<br />
server ptbnts1.ptb.de iburst nts<br />
server ptbnts2.ptb.de iburst nts<br />
server nts.ntp.se iburst nts<br />
server nts.sth1.ntp.se iburst nts<br />
server nts.sth2.ntp.se iburst nts<br />
server time.cloudflare.com iburst nts<br />
<br />
=== Telling chronyd an internet connection has been made ===<br />
<br />
If you are connected to the internet, run:<br />
<br />
{{bc|<br />
# chronyc<br />
chronyc> online<br />
200 OK<br />
chronyc> exit<br />
}}<br />
<br />
You may also be interested in the {{ic|activity}} option to display status:<br />
<br />
{{bc|<br />
# chronyc activity<br />
200 OK<br />
3 sources online<br />
0 sources offline<br />
0 sources doing burst (return to online)<br />
0 sources doing burst (return to offline)<br />
0 sources with unknown address<br />
}}<br />
<br />
Chrony should now connect to the configured time servers and update your clock if needed. To tell chrony that you are not connected to the Internet anymore, execute the following:<br />
<br />
{{bc|<br />
# chronyc offline<br />
200 OK<br />
<br />
# chronyc activity<br />
200 OK<br />
0 sources online<br />
3 sources offline<br />
0 sources doing burst (return to online)<br />
0 sources doing burst (return to offline)<br />
0 sources with unknown address<br />
}}<br />
<br />
The online/offline status can be automatically handled by dispatcher services for {{Pkg|networkmanager}} and {{Pkg|connman}}, see below.<br />
<br />
In conclusion, refer to {{ic|/usr/share/doc/chrony/README}}, which will point you to the right answer to any doubts you could still have. [http://chrony.tuxfamily.org/documentation.html Documentation is also available online.] See also the related man pages: {{ic|man <nowiki>{chronyc|chronyd|chrony.conf}</nowiki>}}).<br />
<br />
<br />
=== For intermittently running desktops ===<br />
<br />
The configuration described here is not really suited well for intermittently running desktops. A machine running Arch Linux for five years, accumulated a 300 s error within the RTC. After a reboot it took chrony a long time to adjust this difference.<br />
<br />
{{hc|/etc/sysconfig/chronyd|output=OPTIONS='-r -s'<br />
}}<br />
<br />
{{hc|/etc/chrony.conf|<br />
dumponexit<br />
dumpdir /var/lib/chrony<br />
rtcfile /var/lib/chrony/rtc<br />
}}<br />
<br />
This keeps, interestingly, the RTC still out-of-date, but after each re-start, chrony adjusts the accumulated error of the RTC and the system time is quite synchronous to NTP even shortly after a start.<br />
<br />
== Usage ==<br />
<br />
=== Starting chronyd ===<br />
<br />
The package provides {{ic|chronyd.service}}, see [[systemd]] for details.<br />
<br />
{{Note| {{ic|systemd-timesyncd.service}} is in conflict with {{ic|chronyd}}, so you need to [[disable]] it first if you want to [[enable]] {{ic|chronyd}} properly.}}<br />
<br />
=== Synchronising chrony hardware clock from the system clock ===<br />
<br />
During boot the initial time is read from the hardware clock (RTC) and the system time is then set, and synchronised over a period of minutes once the chrony daemon has been running for a while. If the hardware clock is out of sync then the initial system time can be some minutes away from the true time. If that is the case it may be necessary to reset the hardware clock.<br />
<br />
You can use chronyc to force the current system time to be synced to hardware:<br />
<br />
{{bc|<br />
# chronyc<br />
chronyc> trimrtc<br />
200 OK<br />
chronyc> quit<br />
}}<br />
<br />
Then exit from chronyc and the RTC and system time should be within a few microseconds of each other and should then be approximately correct on boot and fully synchronise a short time later.<br />
<br />
== Notifying network state ==<br />
<br />
If you have specified your pools as offline in {{ic|chrony.conf}}, you need to tell ''chrony'' that the network status has changed.<br />
<br />
You can either use ''chronyc'' to notify ''chrony'' that your network configuration has changed, or you can use a dispatcher for your relevant network configuration manager.<br />
<br />
=== NetworkManager ===<br />
<br />
''chronyd'' can go into online/offline mode along with a network connection through the use of [[NetworkManager#Network_services_with_NetworkManager_dispatcher|NetworkManager's dispatcher scripts]]. You can install {{AUR|networkmanager-dispatcher-chrony}} from the AUR.<br />
<br />
=== netctl ===<br />
<br />
Install {{AUR|netctl-dispatcher-chrony}} from the AUR. This adds a hook to netctl which is run automatically for any connection.<br />
<br />
=== dhcpcd ===<br />
<br />
Create the following hook:<br />
<br />
{{hc|/etc/dhcpcd.exit-hook|<br />
if $if_up; then<br />
chronyc online<br />
elif $if_down; then<br />
chronyc offline<br />
fi<br />
}}<br />
<br />
See {{man|8|dhcpcd-run-hooks}}<br />
<br />
== See also ==<br />
<br />
* [[System time]] (for more information on computer timekeeping)<br />
* http://chrony.tuxfamily.org/<br />
* http://www.ntp.org/<br />
* http://support.ntp.org/<br />
* http://www.pool.ntp.org/<br />
* http://www.eecis.udel.edu/~mills/ntp/html/index.html<br />
* http://www.akadia.com/services/ntp_synchronize.html</div>Hardfalconhttps://wiki.archlinux.org/index.php?title=TPM2-PK11&diff=631826TPM2-PK112020-08-13T14:38:41Z<p>Hardfalcon: Fixed broken tpm2_* commands in "Create keys" section. tpm2-tools seem to change their command parameters every other week: https://github.com/tpm2-software/tpm2-tools/commits/master/man</p>
<hr />
<div>[[Category:Security]]<br />
[[zh-hans:TPM2-PK11]]<br />
{{Expansion|This is a (now slightly adapted) copy of the README on GitHub. What's this article about? What does it add over the README that shouldn't be maintained there? How do you install this on Arch?}}<br />
<br />
{{AUR|tpm2-pk11-git}} provides a [https://github.com/irtimmer/tpm2-pk11 PKCS#11] backend for a [[TPM]] 2.0 chip.<br />
This can be used to secure your [[SSH keys]].<br />
<br />
{{Note|Only the OpenSSH client is supported as of November 2017.}}<br />
<br />
== SSH Usage ==<br />
<br />
Create keys:<br />
<br />
{{bc|<br />
$ mkdir ~/.tpm2 && cd ~/.tpm2<br />
$ tpm2_createprimary --hierarchy e --hash-algorithm sha256 --key-algorithm ecc256 --key-context primary.ctx<br />
$ tpm2_create --parent-context primary.ctx --hash-algorithm sha256 --key-algorithm ecc256 --public key.pub --private key.priv<br />
$ tpm2_load --parent-context primary.ctx --public key.pub --private key.priv --name key.name --key-context key.ctx<br />
$ tpm2_evictcontrol --hierarchy o --object-context key.ctx 0x81010010<br />
$ rm key.name *.ctx<br />
}}<br />
<br />
Create configuration file and change it for your setup:<br />
<br />
$ cp config.sample ~/.tpm2/config<br />
<br />
Extract public key:<br />
<br />
$ ssh-keygen -D libtpm2-pk11.so<br />
<br />
Use your TPM key:<br />
<br />
$ ssh -I libtpm2-pk11.so ssh.example.com<br />
<br />
Or add the PKCS#11 module to your ssh configuration in {{ic|~/.ssh/config}}:<br />
<br />
{{bc|<br />
Host *<br />
PKCS11Provider libtpm2-pk11.so<br />
}}</div>Hardfalconhttps://wiki.archlinux.org/index.php?title=YubiKey&diff=587577YubiKey2019-11-02T03:56:28Z<p>Hardfalcon: /* Initial configuration */ Fixed forbidden "=" in warning template block</p>
<hr />
<div>[[Category:Authentication]]<br />
[[ja:Yubikey]]<br />
{{Accuracy|The article lacks sources, is interspersed with TODOs and probably out of date.}}<br />
{{Style|ykman-specifics should be grouped together.}}<br />
This article describes how [https://yubico.com Yubico]'s [[Wikipedia:YubiKey|YubiKey]] works and how you can use it.<br />
<br />
{{Note|Before you overwrite the initial configuration of slot 1, please be aware of the warning under [[#Initial configuration]].}}<br />
<br />
== Introduction ==<br />
<br />
The YubiKey is a small [[Wikipedia:Security token|USB Security token]] that supports:<br />
<br />
* generating [[Wikipedia:One-time password|one-time passwords]] (OTP) - using either AES based Yubico OTP algorithm or OATH-HOTP following RFC 4226<br />
* outputting a up to 63 char long static password<br />
* handling [[Wikipedia:Challenge–response authentication|challenge-response requests]], using either Yubico OTP mode or HMAC-SHA1 mode<br />
* handling [[Wikipedia:Universal_2nd_Factor|Universal 2nd Factor]] (U2F) requests (YubiKey 4 and YubiKey NEO)<br />
* acting as smartcard (using the [[Wikipedia:CCID (protocol)|CCID protocol]]) (YubiKey 4 and YubiKey NEO) - allowing storage of signing, encrypting, authenticating (RSA) keys to be used for instance for SSH login (authentication), Email signature/encryption, git commit signature, etc.<br />
<br />
It is manufactured by [http://www.yubico.com/ Yubico].<br />
<br />
One of its strengths is that it emulates a USB keyboard to send the OTP as text, and thus requires only USB HID drivers found on practically all desktop computers.<br />
<br />
=== Installation ===<br />
<br />
There are several packages available:<br />
<br />
* {{App|Yubico PAM|Module to integrate the YubiKey into [[PAM]].|https://developers.yubico.com/yubico-pam/|{{Pkg|yubico-pam}}}}<br />
* {{App|YubiKey Manager|Python library and command-line tool ({{ic|ykman}}) for configuring a YubiKey over all USB connections. Has optional GUI.|https://developers.yubico.com/yubikey-manager/|{{Pkg|yubikey-manager}}, {{Pkg|yubikey-manager-qt}}}}<br />
Note: After you install the yubikey-manager ( which can be called by ykman in cli ), you need to enable pcscd.service to get it running<br />
* {{App|Yubikey Personalization|Library and tool to configure slot features over the OTP USB connection. Has optional GUI.|https://developers.yubico.com/yubikey-personalization/|{{Pkg|yubikey-personalization}}, {{Pkg|yubikey-personalization-gui}}}}<br />
<br />
=== Understanding the YubiKey ===<br />
<br />
The YubiKey is a small USB dongle with one button and an LED to communicate with you.<br />
<br />
One of its strengths is that it can emulate a USB keyboard to send a password (OTP or static password) as text, and thus requires only USB HID drivers found on practically all computers (desktop, mobile, tablet).<br />
<br />
This also makes it vulnerable to keyloggers if the {{ic|static password}} functionality is used, which is why if possible one should avoid it and try to only use the one-time password (OTP), Challenge-Response and CCID Smartcard functionality.<br />
<br />
==== Inputs ====<br />
<br />
The YubiKey takes inputs in the form of:<br />
<br />
* API calls sent to it via the USB interface.<br />
* short button press<br />
* long button press<br />
<br />
==== Outputs ====<br />
<br />
The YubiKey transforms these inputs into outputs in the form of:<br />
<br />
* Sending keystroke keycodes (emulating a USB keyboard and typing for you) <br> This is used to:<br />
** type the static password<br />
** type the OTP<br />
<br />
* Sending back a Response via the API (over the USB interface). <br> This is used to send back:<br />
** the response of a Challenge-Response request (calculated using either Yubico OTP mode or HMAC-SHA1 mode)<br />
** the response of a U2F Challenge-Response request<br />
** the response of a CCID Smartcard related request<br />
<br />
=== The button ===<br />
<br />
The button activates by slightly touching it. Sometimes it even reacts when you are very close but are not touching it yet.<br />
<br />
Depending on the context, touching the button does one of these things:<br />
<br />
* triggering a function (like triggering the output of a static password or of a one-time password (OTP))<br />
* confirming / allowing a function or access<br />
* inserting / ejecting the smartcard<br />
<br />
In the OTP mode a short press yields slot 1 and a long press yields slot 2.<br />
<br />
=== USB connection modes ===<br />
<br />
Depending on the YubiKey model, the device provides up to three<br />
different USB interfaces with their associated protocols. Two of the<br />
interfaces implement the USB HID (Human Interface Device) device<br />
class; the third is a smart card interface (CCID). The YubiKey is a<br />
multi-function USB device, just like a USB printer that can also<br />
function as a scanner.<br />
<br />
The following table shows which interfaces the different applications<br />
use:<br />
<br />
{| class="wikitable"<br />
! Application !! USB Interface<br />
|-<br />
|OTP || Keyboard HID<br />
|-<br />
|FIDO || Other HID<br />
|-<br />
|PIV || CCID<br />
|-<br />
|OpenPGP || CCID<br />
|-<br />
|OATH || CCID<br />
|}<br />
<br />
All three interfaces can be independently enabled or disabled.<br />
The ykman program uses the term "manage connection modes" and uses<br />
OTP, FIDO, and CCID as selectors for which modes should be enabled.<br />
<br />
{{Note|The old U2F mode has been renamed and is now called FIDO in ykman 0.6.1 and later (released<br />
2018-04-16) https://developers.yubico.com/yubikey-manager/Release_Notes.html}}<br />
<br />
The set of enabled USB interfaces affects which applications on the<br />
key can be accessed. As an example, if only the HID interfaces are<br />
enabled, the applications dependent on the CCID interface are<br />
unavailable.<br />
<br />
Which application on the key is chosen is determined by the host<br />
application and is a combination of USB interface and an application<br />
selection mechanism. For example, if the host application wants to<br />
communicate with the PIV application on the key, it accesses the key<br />
using the CCID interface and using the protocols defined by CCID sends<br />
a 'select application' command to the key selecting the PIV application.<br />
<br />
==== Get enabled modes ====<br />
<br />
{{ic|ykman mode}} will tell you what modes are currently activated/enabled/available.<br />
This could output something like<br />
{{bc|Current connection mode is: OTP+U2F+CCID}}<br />
Meaning that currently the OTP, U2F and CCID subsystem of the key are enabled.<br />
<br />
==== Set the enabled modes ====<br />
<br />
{{ic|ykman mode <MODE>}} will allow you to define which modes should be activated/enabled/available. <br />
* {{ic|<MODE>}} can be a string, such as {{ic|OTP+U2F+CCID}}, or a shortened form {{ic|o+u+c}}.<br>With "+" you can combine multiple modes that you wish to be enabled.<br />
* {{ic|<MODE>}} can be a mode-number, which is one number that encodes several enabled modes (like flags) into one value.<br>The only valid modes when using numbers is 0 - 6 ([https://github.com/Yubico/yubikey-manager/blob/master/ykman/util.py#L94 see here]). The extra flags are not part of the mode in that sense, they just need to be set at the same time as the mode is set.<br />
<br />
Usually what you want is to make all functionality available (you will still need to potentially configure stuff, see functionality sections below for more details).<br />
In order to do so you can use:<br />
<br />
{{ic|ykman mode c+u+o}} or {{ic|ykman mode 6}}<br />
<br />
{{Note|Using the "80" mode-number or the corresponding {{ic|--touch-eject}} parameter of {{ic|ykman mode}} can only be used when the device is ''only'' in CCID mode (by running {{ic|ykman mode ccid --touch-eject}} for instance).<br />
<br />
Once the {{ic|--touch-eject}} flag is set, you should be able to eject/insert the smartcard by pressing the button. The LED should indicate if the card is inserted or not as well.<br />
}}<br />
<br />
{{Warning|But using the 80 mode-number or the corresponding {{ic|--touch-eject}} is not recommend as it would prevent you from using the U2F and OTP features of the YubiKey.}}<br />
<br />
{{Note|The often seen:<br />
<br />
{{ic|ykman mode c+u+o --touch-eject}} or {{ic|ykman mode 86}}<br />
<br />
will ignore the {{ic|--touch-eject}} and be identical to the above recommended {{ic|ykman mode 6}}.<br />
<br />
86 is not a valid mode. It might be a bug that the tool accepts higher values ([https://github.com/Yubico/yubikey-manager/issues/20#issuecomment-326496204 see here]).}}<br />
<br />
=== Two Slots ===<br />
<br />
Only if the OTP mode is activated (see Modes of the YubiKey below), the Yubikey provides 2 slots.<br />
<br />
If the transport mode OTP is enabled, the two YubiKey Slots, long press and short press, can be configured and used.<br />
<br />
==== Configuration of the slots ====<br />
<br />
These slots can have one of the following credentials configured: a [https://developers.yubico.com/OTP/ Yubico OTP] (which is what comes preconfigured in the short press slot on a new key), a static password, a challenge-response credential, an OATH-HOTP credential. All this functionality is found in the {{ic|ykman otp}} commands.<br />
<br />
{{Note|A slot has either a Yubico OTP or a challenge-response credential configured. More general: One, and only one, type of the above listed possible credential per slot.}}<br />
<br />
There are several flags that can be set during the configuration of the slots.<br />
These flags /cannot/ be read from the device once written. However, the behaviour of the device should change when the flags are set ;)<br />
<br />
{{Note|Actually most of (all of??) the parameters and details you use during configuration of the slots, cannot be read back, once written to the YubiKey.}}<br />
<br />
=== The LED ===<br />
<br />
The YubiKey has a small green LED able to communicate with you.<br />
Its message to you actually depends on the currently used [[#USB connection modes]] of your YubiKey.<br />
<br />
The possible messages are:<br />
* *steady on*: Press now, to allow access. (typically (TODO exclusively?) U2F mode)<br />
* *slow blinking*: Power/setting up/ready for use (TODO explain)<br />
* *rapid blinking*: Error, configuring driver (TODO explain)<br />
<br />
{{Note|If the CCID mode is turned on, then the LED of the key is always shortly flashing every two-three seconds once inserted.<br>You can turn the blinking off by disabling the CCID mode. This slow blinking just shows that the device has power, alternatively it shows a need for a button press. On Windows this behavior will typically stop once drivers are installed and it is ready for use. Mac and Linux systems will keep blinking; here [https://github.com/Yubico/yubikey-manager/issues/20#issuecomment-326496204 the best current workaround] to get the LED to blink less is to disable CCID.}}<br />
<br />
=== Initial configuration ===<br />
<br />
On a new YubiKey the Yubico OTP is preconfigured on slot 1. <br />
<br />
{{Warning|Before you overwrite your slot 1, please be aware that one is not able to reconfigure the same trust level [https://forum.yubico.com/viewtopic12ca.html?f%3D16&t%3D1960 see here]. Meaning:<br />
<br />
One could think that it is a good idea to reset configuration slot 1 to a new OTP. But then a "VV" prefix in your credentials must be used. Whereas the factory credentials on your Yubikey use a "CC" prefix. You can upload a "VV" credential using the Yubico personalization tool GUI or manually upload the new AES key to the [https://upload.yubico.com/ yubico.com website] in order to regain the same functionality than with the original factory configuration. VV credentials are not less secure than CC. However some services may only trust CC credentials as they believe that the user process is more prone to security vulnerabilities. This is because you could have malware on your machine or someone intercepting your key when sending it to the YubiCloud.<br />
}}<br />
<br />
=== Limitations of the passwords typed by YubiKey via USB-keyboard -- or "Why do my password look so weak ?" ===<br />
<br />
The YubiKey can type passwords (OTP or Static Password) for you by acting as USB keyboard and sending scan-codes like if you would type.<br />
<br />
A limitation of the YubiKey, however, prevents you from choosing characters that require a modifier key other than Shift.<br />
And in order for the YubiKey to work with all possible keyboard layouts (e.g. the {{ic|Z}} on a German keyboard has a different scan-code than the {{ic|Z}} on a US keyboard) it is necessary to limit the characters used by YubiKey passwords to the ModHex alphabet + Digits (0-9) (+ optionally "!" as the only available Symbol in static passwords).<br />
<br />
The 16 characters used in the ModHex alphabet are: {{ic|c,b,d,e,f,g,h,i,j,k,l,n,r,t,u,v}}. These characters share a property that makes them very valuable to a YubiKey: They use the same scan codes across a very large number of keyboard layouts. In other words, the scan code 0x06 maps to the character c for English, Swedish, German, French, and many others.<br />
<br />
[https://www.yubico.com/wp-content/uploads/2015/11/Yubico_WhitePaper_Static_Password_Function.pdf See here for full info]<br />
<br />
== One-time password ==<br />
<br />
=== Yubico OTP mode ===<br />
<br />
The Yubico OTP mode is AES symmetric key based. On a new YubiKey the Yubico OTP is preconfigured on slot 1. This initial AES symmetric key is stored in the YubiKey and the same AES key is already stored on the Yubico Authentication server. This allows validating against YubiCloud, meaning the use of Yubico OTP in combination with the Yubico Forum website for instance or on https://demo.yubico.com).<br />
<br />
The initial configuration and AES key stored in slot 1 can of course be overwritten.<br />
<br />
{{Warning|Please read [[#Initial configuration]] before you overwrite the intial configuration of slot 1 that your YubiKey comes shipped with.}}<br />
<br />
==== How does it work ====<br />
<br />
Yubikey's authentication protocol is based on [[Wikipedia:Symmetric_cryptography|symmetric cryptography]].<br />
More specifically, each YubiKey contains a 128-bit [[Wikipedia:Advanced_Encryption_Standard|AES]] key unique to that device.<br />
It is used to encrypt a token made of different fields such as the ID of the key, a counter, a random number, etc.<br />
The OTP is made from concatenating the ID of the key with this encrypted token.<br />
<br />
This OTP is sent to the target system to which we want to authenticate.<br />
This target system asks a validation server if the OTP is good.<br />
The validation server has a mapping of YubiKey IDs -> AES key.<br />
Using the key ID in the OTP, it can thus retrieve the AES key and decrypt the other part of the OTP.<br />
If it looks OK (plain-text ID and encrypted ID are the same, the counter is bigger than the last seen one to prevent [[wikipedia:Replay_attack|replay attacks]], then authentication is successful.<br />
<br />
The validation server sends that authentication status back to the target system, which grants access or not based on that response.<br />
<br />
==== Security risks ====<br />
<br />
===== AES key compromise =====<br />
<br />
As you can imagine, the AES key should be kept secret.<br />
It cannot be retrieved from the YubiKey itself (or it should not, at least not with software).<br />
It is present in the validation server though, so the security of this server is very important.<br />
<br />
===== Validation requests/responses tampering =====<br />
<br />
Since the target system relies on the ruling of the validation server, a trivial attack would be to impersonate the validation server.<br />
The target system thus needs to authenticate the validation server.<br />
2 methods are available :<br />
* '''HMAC''': This is also symmetric cryptography, the target server and validation server share a key that is used to sign requests and responses.<br />
* '''TLS''': Requests and responses travel via HTTP, so TLS (HTTPS) can be used to authenticate and encrypt the connection.<br />
<br />
==== YubiCloud and validation servers ====<br />
<br />
When you buy a YubiKey, it is preloaded with an AES key that is known only to Yubico.<br />
They will not even communicate it to you.<br />
Yubico provides a validation server with free unlimited access (YubiCloud).<br />
It also offers open-source implementations of the server.<br />
<br />
So you can either:<br />
* choose to use your YubiKey with its preloaded AES key and validate against Yubico's validation server ;<br />
* or load a new AES key in your YubiKey and run your own validation server.<br />
<br />
{{Note|To authenticate the Yubico validation server, you can:<br />
* '''with HMAC''': use https://upgrade.yubico.com/getapikey/ to get an HMAC key and ID<br />
* '''with HTTPS''': the validation server's certificate is signed by GoDaddy, and is thus trusted by default in Arch installs (at least if you have package ca-certificates)}}<br />
<br />
=== OATH-HOTP mode (RFC 4226) ===<br />
<br />
{{Expansion|Empty section.}}<br />
<br />
== Challenge-Response ==<br />
<br />
=== Function and Application of Challenge-Response ===<br />
This technique can be used to authenticate.<br />
<br />
A challenge is sent to the YubiKey and a response is (auto-magically) calculated and send back.<br />
This calculation needs a secret (e.g. an AES key in case of the Yubico OTP mode)<br />
The same challenge always results in the same response.<br />
Without the secret this calculation is not meant to be feasable. Even if in the possession of many challenge-response pairs.<br />
<br />
This can be used for:<br />
* true 2-factor (possession and knowledge) authentication:<br>If you combine the response (possession factor) with a password (knowledge factor) and to authenticate you need to present the triple (challenge,response, password) to 3rd party. In which case the challenge and the corresponding response can be (publicly) send to a 3rd party to authenticate the possession factor, by redoing basically the same (auto-magical) calculation. The needed secret needs to be shared with 3rd party to allow an authentication.<br />
<br />
* semi 2-factor (possession and knowledge) authentication:<br>The challenge can be public. Only with the possession of the YubiKey hardware the response can be generated. This can be used to create a "sort-of" 2-factor authentication (possession and knowledge): If you combine the response (possession factor) with a password (knowledge factor) and use the result for instance as passphrase for cryptsetup.<br />
<br />
This functionality will consume one slot. And it is used via API calls to the YubiKey. So you usually use some tool to communicate the challenge to your YubiKey and get back the response.<br />
<br />
There are two Challenge-Response modes:<br />
* Yubico OTP mode <br />
* HMAC-SHA1 mode<br />
<br />
=== Setup the slot ===<br />
<br />
{{Style|Duplicates {{man|1|ykpersonalize}}.}}<br />
<br />
In order to setup slot {{ic|2}} in challenge-response mode you may run:<br />
<br />
{{bc|ykpersonalize -v -2 -ochal-resp -ochal-hmac -ohmac-lt64 -oserial-api-visible -ochal-btn-trig}}<br />
<br />
Above arguments mean:<br />
* Verbose output ({{ic|-v}})<br />
* Use slot 2 ({{ic|-2}})<br />
* Set challenge-response mode ({{ic|-ochal-resp}})<br />
* Generate HMAC-SHA1 challenge responses ({{ic|-ochal-hmac}})<br />
* Calculate HMAC on less than 64 bytes input ({{ic|-ohmac-lt64}})<br />
* Allow Yubikey serial number to be read using an API call ({{ic|-oserial-api-visible}})<br />
* Require touching Yubikey before issue response ({{ic|-ochal-btn-trig}})<br />
<br />
You may also enable challenge-response mode using graphical interface through {{pkg|yubikey-personalization-gui}}<br />
<br />
{{Note|Before you overwrite the initial configuration of slot 1, please be aware of the '''Warning''' under [[#Initial configuration]].}}<br />
<br />
=== Use the slot - get a response for a challenge ===<br />
<br />
To use a Challenge-Response slot (no matter which mode):<br />
<br />
{{bc|ykchalresp -2 <CHALLENGE>}}<br />
<br />
== U2F ==<br />
<br />
{{Expansion}}<br />
<br />
=== Enabling U2F in the browser ===<br />
<br />
==== Chromium/Chrome ====<br />
<br />
[[Chromium/Tips and tricks#U2F authentication]]<br />
<br />
==== Firefox ====<br />
<br />
[[Firefox/Tweaks#Fido U2F authentication]]<br />
<br />
== CCID Smartcard ==<br />
<br />
CCID (Chip Card Interface Device) is a USB standard device class for use by USB devices that act as smart card readers or with security tokens that connect directly via USB, like the Yubikey. HID (Human Interface Device) and CCID are both USB device classes, i.e. they are in the same category of USB specifications. HID is a specification for computer peripherals, like keyboards. The Yubikey works like a USB (HID) keyboard when used in the OTP and U2F modes, but switches to the CCID protocol when using the PIV application, or as an OpenPGP device.<br />
<br />
CCID mode should be enabled by default on all YubiKeys shipped since November 2015 [https://www.yubico.com/support/knowledge-base/categories/articles/use-yubikey-yubikey-windows-hello-app/]. Enable at least the CCID mode. Please see [[#Set the enabled modes]].<br />
<br />
=== PIV ===<br />
<br />
Starting from the fourth generation devices, the Yubikeys contain a PIV (Personal Identity Verification) application on the chip. PIV is a US government standard (FIPS 201) that specifies how a token using RSA or ECC (Elliptic Curve Cryptography) is used for personal electronic identification. The distinguishing characteristic of a PIV token is that it is built to protect private keys and operate on them on-chip. A private key never leaves the token after it has been installed on it. Optionally, the private key can even be generated on-chip with the aid of an on-chip random number generator. If generated on-chip, the private key is never handled outside of the chip, and there is no way to recover it from the token. When using the PIV mechanism, the Yubikey functions as a CCID device.<br />
<br />
=== Use OpenPGP smartcard mode ===<br />
<br />
See [[GnuPG#Smartcards]]<br />
<br />
=== Using a YubiKey with SSH ===<br />
<br />
The following example describes how to use a YubiKey for [[SSH keys]]. A YubiKey with the PIV (Personal Identification Verification) application is required; this means you need a YubiKey NEO or YubiKey 4 or later.<br />
<br />
==== Generating a key pair on the YubiKey ====<br />
<br />
A private key and associated certificate need to be either generated on the YubiKey or imported to it. Install the {{Pkg|yubikey-manager}}<br />
package. Insert the YubiKey in a USB port and check that it is recognized:<br />
<br />
$ ykman list<br />
YubiKey 4 [OTP+FIDO+CCID] Serial: 1234567<br />
<br />
The following two commands ({{ic|generate-key}} and {{ic|generate-certificate}}) require providing the PIV application's 24-byte management key, if it has been changed from its default value (recommended). The examples below assume the shell variable {{ic|MK}} has been set in advance to the 48 character hex string representation of the management key. For example:<br />
<br />
$ MK=AB019982CA48BDC6776B1F9A0A3E129FDE0705D219AF0037<br />
<br />
Generate a 2048-bit RSA key pair on the YubiKey. The private key will be stored in key slot 9a on the YubiKey, and the public key will be<br />
written to the file {{ic|pubkey.pem}}.<br />
<br />
$ ykman piv generate-key -m $MK -a RSA2048 9a pubkey.pem<br />
<br />
Next, use the YubiKey to generate a self-signed certificate for the public key:<br />
<br />
$ ykman piv generate-certificate -m $MK -d 1826 -s "SSH Key" 9a pubkey.pem<br />
<br />
The Subject field in the certificate will be set to "SSH Key" with the {{ic|-s}} option. This field will be included in the prompt for PIN to help identify which key is used for authentication. The example command also specifies the {{ic|-d}} option to set the number of days until the certificate expires. If the {{ic|-d}} option is omitted, a default value of 365 days is used.<br />
<br />
Note that the last parameter in the {{ic|generate-key}} command is the file name where the public key is written to, whereas the last parameter in the {{ic|generate-certificate}} command specifies where the public key is read from. The certificate is constructed and signed on the YubiKey and stored alongside the private key; the command does not output the certificate.<br />
<br />
At this point the YubiKey is ready for authenticating to a SSH server. For this to happen, some additional configuration on both the client and the server is required.<br />
<br />
==== Client configuration ====<br />
<br />
The standard API used to communicate with cryptographic tokens is defined by [[wikipedia:PKCS_11|PKCS#11]].<br />
Install the {{Pkg|opensc}} package which provides this API in the form of the shared library {{ic|/usr/lib/opensc-pkcs11.so}}. The ssh client should be configured to use this library with the directive PKCS11Provider in {{ic|~/.ssh/config}}:<br />
<br />
{{hc|~/.ssh/config|PKCS11Provider /usr/lib/opensc-pkcs11.so}}<br />
<br />
==== Public key conversion ====<br />
<br />
The {{ic|pubkey.pem}} file contains the public key in PEM (Privacy Enhanced Mail) format. OpenSSH uses a different format defined in RFC 4253,<br />
section 6.6, so the PEM formatted key should be converted to the format OpenSSH understands. This can be done using ''ssh-keygen'':<br />
<br />
$ ssh-keygen -i -m PKCS8 -f pubkey.pem > pubkey.txt<br />
<br />
This command uses the import ({{ic|-i}}) function of the ''ssh-keygen'' program, specifies PKCS8 as the input file format ({{ic|-m}}), and reads the input from the ({{ic|-f}}) file {{ic|pubkey.pem}}. The converted key is written on standard output, which is the example is redirected to the file {{ic|pubkey.txt}}.<br />
<br />
The converted public key should now be copied to the remote server as described in [[SSH keys#Copying the public key to the remote server]].<br />
<br />
==== Initiating an SSH session with the YubiKey ====<br />
<br />
To authenticate a SSH connection using the YubiKey, just use ''ssh'' normally. You will be prompted for the PIN instead of a password:<br />
<br />
$ ssh remote<br />
Enter PIN for 'SSH Key' <br />
[user@remote ~]$ <br />
<br />
==== Using ssh-agent to cache the PIN ====<br />
<br />
ssh-agent (see [[SSH keys#SSH agents]]) can also be used with the PKCS#11 library; in this case the PIN code is cached instead of the private key.<br />
<br />
$ ssh-add -s /usr/lib/pkcs11/opensc-pkcs11.so<br />
<br />
As long as the PIN is cached in by the agent, the cached value is used and the user is not prompted for it.<br />
<br />
==== Further reading ====<br />
<br />
The default PIN code of the PIV application on the YubiKey is {{ic|123456}}; you may want to change it. The YubiKey also requires a 24-byte management key for administrative functions like key generation. If the management key has been changed from its default value, the new value needs to be specified using the -m option on the command line for certain commands. See [https://developers.yubico.com/PIV/ What is PIV?]<br />
<br />
== Tips and tricks ==<br />
<br />
=== YubiKey and LUKS encrypted partition/disk ===<br />
<br />
YubiKey can be used to strengthen the security of your [[LUKS]] encrypted partition/disk.<br />
<br />
One way to achieve it is to use a Challenge-Response mode for creating strong LUKS passphrases. [https://github.com/agherzan/yubikey-full-disk-encryption yubikey-full-disk-encryption] is a robust and comfortable to use implementation of an [[initramfs]] hook and on-demand scripts to create/open LUKS encrypted partitions/disks using a stored or manually provided challenge.<br />
<br />
Another way of using YubiKey for full disk encryption is to utilize its OpenPGP applet to decrypt the LUKS keyfile during boot. [https://github.com/fuhry/initramfs-scencrypt initramfs-scencrypt] is a set of hooks for initramfs that automate this process.<br />
<br />
=== Yubikey and KeePass ===<br />
<br />
{{Style|Duplicates [[KeePass]].}}<br />
<br />
Yubikey can be integrated with [[KeePass]] using [[KeePass#Yubikey|plugins]].<br />
<br />
For a native open-source implementation of KeePass have a look at:<br />
<br />
==== keepassx2 ====<br />
<br />
{{AUR|keepassx2}} ([https://keepassx.org/ see keepassx.org]) a keepass QT FOSS reimplementation, extremely stable and available for Windows, MacOSX and Linux.<br />
<br />
==== KeePassXC ====<br />
<br />
{{Pkg|keepassxc}} ([https://keepassxc.org/ see keepassxc.org]) a KeePassX fork that integrated YubiKey into KeePassX v2.<br>The integration covers Challenge-Response as security factor to open the database, but also the generation of OTP using the YubiKey.<br />
<br />
In order to have a KeePassXC database work on Android (using the [https://play.google.com/store/apps/details?id=keepass2android.keepass2android Keepass2Android app]), you need to use version 1.06 of the app. You also need to save the database file in the KDBX 4 format, since Keepass2Android do not support the KDBX 3 format.<br />
<br />
YubiKey support in Keepass2Android (which is compatible with KeePassXC) is tracked [https://github.com/PhilippC/keepass2android/issues/4 on GitHub].<br />
<br />
=== Two-factor authentication with SSH ===<br />
<br />
{{Note|See also: https://developers.yubico.com/yubico-pam/Yubikey_and_SSH_via_PAM.html}}<br />
<br />
This details how to use a Yubikey to have [[wikipedia:Two-factor_authentication|two-factor authentication]] with SSH, that is, to use both a password and a Yubikey-generated OTP.<br />
<br />
==== Prerequisites ====<br />
<br />
Install {{Pkg|yubico-pam}}.<br />
<br />
{{Note|If you are configuring a distant server to use Yubikey, you should open at least one additional, rescue SSH session, so that you are not locked out of your server if the configuration does not work and you exit your main session inadvertently}}<br />
<br />
{{Note|The following assumes you are using the default Yubico servers. See the [https://github.com/Yubico/yubico-pam yubico-pam documentation] for options relevant to using your own server.}}<br />
<br />
==== Configuration ====<br />
<br />
===== Authorization Mapping Files =====<br />
<br />
A mapping must be made between the YubiKey token ID and the user ID it is<br />
attached to. There are two ways to do this, either centrally in one file, or<br />
individually, where users can create the mapping in their home directories.<br />
If the central authorization mapping file is being used, user home directory<br />
mappings will not be used and vice versa.<br />
<br />
====== Central authorization mapping ======<br />
<br />
Create a file {{ic|/etc/yubico/authorized_yubikeys}}, the file must contain a user name and the<br />
Yubikey token ID separated by colons (same format as the passwd file) for<br />
each user you want to allow onto the system using a Yubikey.<br />
<br />
The mappings should look like this, one per line:<br />
<br />
<first user name>:<Yubikey token ID1>:<Yubikey token ID2>:...<br />
<second user name>:<Yubikey token ID3>:<Yubikey token ID4>:...<br />
<br />
You can specify multiple key tokens to correspond to one user, but only one is required.<br />
<br />
====== Per-user authorization mapping ======<br />
<br />
Each user creates a {{ic|~/.yubico/authorized_yubikeys}} file inside of their home<br />
directory and places the mapping in that file, the file must have only one<br />
line:<br />
<br />
<user name>:<Yubikey token ID1>:<Yubikey token ID2><br />
<br />
This is much the same concept as the SSH authorized_keys file.<br />
<br />
Note that this file must be readable by the {{ic|pam_yubico}} module when the user is authenticated, otherwise login will fail. If this is not possible or desired, use the global mapping file instead.<br />
<br />
====== Obtaining the YubiKey token ID (a.k.a. public ID) ======<br />
<br />
You can obtain the YubiKey token ID in several ways. One is by<br />
removing the last 32 characters of any OTP (One Time Password)<br />
generated with your YubiKey. Another is by using the<br />
[http://demo.yubico.com/php-yubico/Modhex_Calculator.php modhex calculator].<br />
<br />
Enter your YubiKey OTP and convert it, your Yubikey token ID is 12<br />
characters and listed as:<br />
<br />
Modhex encoded: XXXXXXX<br />
<br />
===== PAM configuration =====<br />
<br />
Having set up the {{ic|pam_yubico}} module, you next need to tell PAM to use it when logging in via SSH. There are several ways of doing this.<br />
<br />
====== The default way ======<br />
<br />
Obtain HMAC credentials from Yubico as described in [[#YubiCloud and validation servers]]. You will receive a Client ID and a secret key.<br />
<br />
Add one of the two following lines to the beginnning of {{ic|/etc/pam.d/sshd}}:<br />
<br />
auth required pam_yubico.so id=CLIENTID authfile=/etc/yubico/authorized_yubikeys<br />
<br />
if you are using a central authorization mapping file, or<br />
<br />
auth required pam_yubico.so id=CLIENTID<br />
<br />
if you are using per-user authorization mapping, where {{ic|CLIENTID}}} is your Client ID. This method utilizes your ID and the server's certificate to authenticate the connection.<br />
<br />
{{Note|This will authenticate via Yubico's free YubiCloud servers. If you want to use a different server, add it via the {{ic|urllist}} parameter.}}<br />
<br />
====== Using pure HMAC to authenticate the validation server ======<br />
<br />
Add {{ic|key}} to the above lines in {{ic|/etc/pam.d/sshd}}:<br />
<br />
auth required pam_yubico.so id=CLIENTID key=SECRETKEY ...<br />
<br />
where {{ic|CLIENTID}} and {{ic|SECRETKEY}} are your HMAC ID and key.<br />
<br />
You should also disallow unprivileged users to read the file to prevent them from seeing the HMAC credentials:<br />
# chmod o-r /etc/pam.d/sshd<br />
<br />
{{Note|HMAC credentials should be unique to a single target server. That way, if an attacker finds them, he will not be able to craft responses to authenticate to other target servers you own}}<br />
<br />
====== Using pure HTTPS to authenticate the validation server ======<br />
<br />
{{Warning|While this "old" method of using a dummy id still works, it is unknown how secure and/or future-proof it is, as Yubico no longer describes it in their documentation. Proceed at your own risk. At the very least you should ensure that only HTTPS servers with valid certificates are used for authentication.}}<br />
<br />
If you do not want to use HMAC credentials from Yubico, it is still possible to authenticate via the Yubico server by setting {{ic|1=CLIENTID=1}} instead of your own ID. Although {{ic|pam_yubico}}'s default server uses HTTPS already, for security reasons you should specify it manually via the {{ic|urllist}} parameter, as the servers certificate is the only way in which the connection is authenticated. You can find the keyserver URL by adding the {{ic|debug}} parameter to the {{ic|auth}} line.<br />
<br />
===== SSHD configuration =====<br />
<br />
You should check that {{ic|/etc/ssh/sshd_config}} contains these lines and that they are not commented. The {{ic|sshd_config}} shipped with {{pkg|openssh}} has these set correctly by default.<br />
ChallengeResponseAuthentication no<br />
UsePAM yes<br />
<br />
==== That is it! ====<br />
<br />
You should not need to restart anything if you did not change the SSHD config file.<br />
<br />
To log in, at the {{ic|Password:}} prompt of SSH, you have to type your password '''without pressing enter''' and touch the Yubikey's button.<br />
The Yubikey should send a return at the end of the OTP so you do not need to touch the enter key at all.<br />
<br />
You can display information about the login data generated by {{ic|pam_yubico}} by adding the {{ic|debug}} option to the auth line in{{ic|/etc/pam.d/sshd}}. However, if you are using a central authorization file, you should remove that option once finished testing, as it causes {{ic|pam_yubico}} to display the entire content of the central file to every user who logs in using a Yubikey.<br />
<br />
==== Explanation ====<br />
<br />
This works because the prompt is {{ic|pam_yubico.so}}'s one, since this module is before {{ic|pam_unix.so}}, which normally does basic password authentication.<br />
So, you are giving a string that is the concatenation of your password and the OTP to {{ic|pam_yubico.so}}.<br />
Since the OTPs have a fixed length (let us call this size N), it just has to get the last N characters to retrieve the OTP, and it assumes that the other characters at the start are the password.<br />
It tries to validate the OTP, and in case of success, sends the password to the next PAM module. In Archlinux' default PAM stack, the authenticator {{ic|pam_unix.so}} is instructed to try receiving a password from the previous module with {{ic|try_first_pass}}, so it automatically uses the password sent by {{ic|pam_yubico.so}}.<br />
<br />
=== Executing actions on insertion/removal of yubikey device ===<br />
<br />
For example, you want to perform an action when you pull your yubikey out of the USB slot, create {{ic|/etc/udev/rules.d/80-yubikey-actions.rules}} and add the following contents:<br />
ACTION=="remove", ENV{ID_MODEL}=="Yubikey_4_OTP+U2F+CCID", ENV{ID_VENDOR_ID}=="1050", ENV{ID_MODEL_ID}=="0407", RUN+="/usr/local/bin/script args"<br />
<br />
Please note, that this example is for the yubikey 4, and you will have to look at the output of lsusb to get the vendor and model ID's, along with the description of the device. Of course, to execute a script on insertion, you would change the action to 'add' instead of remove.<br />
<br />
== Maintenance / Upgrades ==<br />
<br />
=== Installing the OATH Applet for a YubiKey NEO ===<br />
<br />
These steps will allow you to install the OATH applet onto your YubiKey NEO. This allows the use of Yubico Authenticator in the Google Play Store.<br />
{{Note|1=These steps are only for NEOs with a firmware version <= 3.1.2. The current generation NEOs (with U2F) come with the OpenPGP applet already installed)}}<br />
<br />
==== Configure the NEO as a CCID Device ====<br />
<br />
# Install {{pkg|yubikey-personalization-gui}} ({{AUR|yubikey-personalization-gui-git}}).<br />
# Add the udev rules and reboot so you can manage the YubiKey without needing to be root<br />
# Run {{ic|ykpersonalize -m82}}, enter {{ic|y}}, and hit enter.<br />
<br />
==== Install the Applet ====<br />
<br />
# Install {{AUR|gpshell}}, {{AUR|gppcscconnectionplugin}}, {{AUR|globalplatform}}, and {{Pkg|pcsclite}}.<br />
# [[Start]] {{ic|pcscd.service}}.<br />
# Download the most recent CAP file from the [http://opensource.yubico.com/ykneo-oath/releases.html ykneo-oath] site.<br />
# Download {{ic|gpinstall.txt}} from [https://github.com/Yubico/ykneo-oath/blob/master/gpinstall.txt GitHub].<br />
# Edit the line in gpinstall.txt beginning with {{ic|install -file}} to reflect the path where the CAP file is located.<br />
# Open a terminal and run {{ic| gpshell <location of gpinstall.txt>}}<br />
# Ideally, a bunch of text will scroll by and it ends saying something like<br />
{{ bc | Command --> 80E88013D7C000C400BE00C700CA00CA00B400BE00CE00D200D500D700B000DB00C700DF00BEFFFF00BE00E400AC00AE00AE00DB00E700A<br />
A00EA00ED00ED00ED00BE00EF00F100F400F100F700FA00FF00BE00F700AA01010103010700CA00C400B400AA00F700B400AA00B600C7010C<br />
010C00AA0140012001B0056810B0013005600000056810E0011006B4B44304B44404B44106B44B4405B443400343B002410636810E06B4B44<br />
407326810B004B43103441003334002B102B404B3B403BB4003B440076820A4100221024405B4341008B44600000231066820A100<br />
Wrapped command --> 84E88013DFC000C400BE00C700CA00CA00B400BE00CE00D200D500D700B000DB00C700DF00BEFFFF00BE00E400AC00AE00AE00DB00E700A<br />
A00EA00ED00ED00ED00BE00EF00F100F400F100F700FA00FF00BE00F700AA01010103010700CA00C400B400AA00F700B400AA00B600C7010C<br />
010C00AA0140012001B0056810B0013005600000056810E0011006B4B44304B44404B44106B44B4405B443400343B002410636810E06B4B44<br />
407326810B004B43103441003334002B102B404B3B403BB4003B440076820A4100221024405B4341008B44600000231066820A15D848CB77<br />
27D0EDA00<br />
Response <-- 009000<br />
Command --> 80E60C002107A000000527210108A00000052721010108A000000527210101010003C901000000<br />
Wrapped command --> 84E60C002907A000000527210108A00000052721010108A000000527210101010003C9010000B4648127914A4C7C00<br />
Response <-- 009000<br />
card_disconnect<br />
release_context}}<br />
# Unplug the NEO and try it with the Yubico Authenticator app<br />
<br />
==== (Optional) Install the Yubico Authenticator Desktop client ====<br />
<br />
You can get the desktop version of the Yubico Authenticator by installing {{AUR|yubico-yubioath-desktop}}{{Broken package link|package not found}} or {{AUR|yubico-yubioath-desktop-git}}.<br />
<br />
While {{ic|pcscd.service}} is running, run {{ic|yubioath-gui}} and insert your Yubikey when prompted.<br />
<br />
== Troubleshooting ==<br />
<br />
Restart, especially if you have completed updates since your Yubikey last worked. Do this even if some functions appear to be functioning.<br />
<br />
=== YubiKey not acting as HID device ===<br />
Add udev rule as described in [https://michaelheap.com/yubikey-on-arch/ this article]:<br />
<br />
{{hc|/etc/udev/rules.d/10-security-key.rules|2=<br />
KERNEL=="hidraw*", SUBSYSTEM=="hidraw", MODE="0664", GROUP="users", ATTRS{idVendor}=="2581", ATTRS{idProduct}=="f1d0"<br />
}}<br />
<br />
Run {{ic|udevadm trigger}} afterwards.<br />
<br />
You may also need to [[install]] the package {{pkg|libu2f-host}} if you want support in chrome.<br />
<br />
=== ykman fails to connect to the YubiKey ===<br />
<br />
If the manager fails to connect to the YubiKey, make sure you have started {{ic|pcscd.service}} or {{ic|pcscd.socket}}.<br />
<br />
=== YubiKey fails to bind within a guest VM ===<br />
<br />
Assuming the Yubikey is available to the guest, the issue results from a driver binding to the device on the host. To unbind the device, the bus and port information is needed from {{ic|dmesg}} on the host:<br />
<br />
$ dmesg | grep -B1 Yubico | tail -n 2 | head -n 1 | sed -E 's/^\<nowiki>[[^]]</nowiki>+\] usb (<nowiki>[^:]</nowiki>*):.*/\1/'<br />
<br />
The resulting USB id should be of the form {{ic|X-Y.Z}} or {{ic|X-Y}}. Then, on the host, use {{ic|find}} to search {{ic|/sys/bus/usb/drivers}} for which driver the Yubikey is binded to (e.g. {{ic|usbhid}} or {{ic|usbfs}}).<br />
<br />
$ find /sys/bus/usb/drivers -name "*X-Y.Z*"<br />
<br />
To unbind the device, use the result from the previous command (i.e. {{ic|/sys/bus/usb/drivers/<DRIVER>/X-Y.Z:1.0}}):<br />
<br />
# echo 'X-Y.Z:1.0' > /sys/bus/usb/drivers/<DRIVER>/unbind<br />
<br />
=== Error: [key] could not be locally signed or gpg: No default secret key: No public key ===<br />
<br />
Occurs when attempting to sign keys on a non-standard keyring while a YubiKey is plugged in, e.g. as [[Pacman/Package_signing|Pacman]] does in {{ic|pacman-key --populate archlinux}}. The solution is to remove the offending YubiKey and start over.</div>Hardfalconhttps://wiki.archlinux.org/index.php?title=YubiKey&diff=587576YubiKey2019-11-02T03:51:53Z<p>Hardfalcon: /* Initial configuration */ Fixed link to Yubico forum</p>
<hr />
<div>[[Category:Authentication]]<br />
[[ja:Yubikey]]<br />
{{Accuracy|The article lacks sources, is interspersed with TODOs and probably out of date.}}<br />
{{Style|ykman-specifics should be grouped together.}}<br />
This article describes how [https://yubico.com Yubico]'s [[Wikipedia:YubiKey|YubiKey]] works and how you can use it.<br />
<br />
{{Note|Before you overwrite the initial configuration of slot 1, please be aware of the warning under [[#Initial configuration]].}}<br />
<br />
== Introduction ==<br />
<br />
The YubiKey is a small [[Wikipedia:Security token|USB Security token]] that supports:<br />
<br />
* generating [[Wikipedia:One-time password|one-time passwords]] (OTP) - using either AES based Yubico OTP algorithm or OATH-HOTP following RFC 4226<br />
* outputting a up to 63 char long static password<br />
* handling [[Wikipedia:Challenge–response authentication|challenge-response requests]], using either Yubico OTP mode or HMAC-SHA1 mode<br />
* handling [[Wikipedia:Universal_2nd_Factor|Universal 2nd Factor]] (U2F) requests (YubiKey 4 and YubiKey NEO)<br />
* acting as smartcard (using the [[Wikipedia:CCID (protocol)|CCID protocol]]) (YubiKey 4 and YubiKey NEO) - allowing storage of signing, encrypting, authenticating (RSA) keys to be used for instance for SSH login (authentication), Email signature/encryption, git commit signature, etc.<br />
<br />
It is manufactured by [http://www.yubico.com/ Yubico].<br />
<br />
One of its strengths is that it emulates a USB keyboard to send the OTP as text, and thus requires only USB HID drivers found on practically all desktop computers.<br />
<br />
=== Installation ===<br />
<br />
There are several packages available:<br />
<br />
* {{App|Yubico PAM|Module to integrate the YubiKey into [[PAM]].|https://developers.yubico.com/yubico-pam/|{{Pkg|yubico-pam}}}}<br />
* {{App|YubiKey Manager|Python library and command-line tool ({{ic|ykman}}) for configuring a YubiKey over all USB connections. Has optional GUI.|https://developers.yubico.com/yubikey-manager/|{{Pkg|yubikey-manager}}, {{Pkg|yubikey-manager-qt}}}}<br />
Note: After you install the yubikey-manager ( which can be called by ykman in cli ), you need to enable pcscd.service to get it running<br />
* {{App|Yubikey Personalization|Library and tool to configure slot features over the OTP USB connection. Has optional GUI.|https://developers.yubico.com/yubikey-personalization/|{{Pkg|yubikey-personalization}}, {{Pkg|yubikey-personalization-gui}}}}<br />
<br />
=== Understanding the YubiKey ===<br />
<br />
The YubiKey is a small USB dongle with one button and an LED to communicate with you.<br />
<br />
One of its strengths is that it can emulate a USB keyboard to send a password (OTP or static password) as text, and thus requires only USB HID drivers found on practically all computers (desktop, mobile, tablet).<br />
<br />
This also makes it vulnerable to keyloggers if the {{ic|static password}} functionality is used, which is why if possible one should avoid it and try to only use the one-time password (OTP), Challenge-Response and CCID Smartcard functionality.<br />
<br />
==== Inputs ====<br />
<br />
The YubiKey takes inputs in the form of:<br />
<br />
* API calls sent to it via the USB interface.<br />
* short button press<br />
* long button press<br />
<br />
==== Outputs ====<br />
<br />
The YubiKey transforms these inputs into outputs in the form of:<br />
<br />
* Sending keystroke keycodes (emulating a USB keyboard and typing for you) <br> This is used to:<br />
** type the static password<br />
** type the OTP<br />
<br />
* Sending back a Response via the API (over the USB interface). <br> This is used to send back:<br />
** the response of a Challenge-Response request (calculated using either Yubico OTP mode or HMAC-SHA1 mode)<br />
** the response of a U2F Challenge-Response request<br />
** the response of a CCID Smartcard related request<br />
<br />
=== The button ===<br />
<br />
The button activates by slightly touching it. Sometimes it even reacts when you are very close but are not touching it yet.<br />
<br />
Depending on the context, touching the button does one of these things:<br />
<br />
* triggering a function (like triggering the output of a static password or of a one-time password (OTP))<br />
* confirming / allowing a function or access<br />
* inserting / ejecting the smartcard<br />
<br />
In the OTP mode a short press yields slot 1 and a long press yields slot 2.<br />
<br />
=== USB connection modes ===<br />
<br />
Depending on the YubiKey model, the device provides up to three<br />
different USB interfaces with their associated protocols. Two of the<br />
interfaces implement the USB HID (Human Interface Device) device<br />
class; the third is a smart card interface (CCID). The YubiKey is a<br />
multi-function USB device, just like a USB printer that can also<br />
function as a scanner.<br />
<br />
The following table shows which interfaces the different applications<br />
use:<br />
<br />
{| class="wikitable"<br />
! Application !! USB Interface<br />
|-<br />
|OTP || Keyboard HID<br />
|-<br />
|FIDO || Other HID<br />
|-<br />
|PIV || CCID<br />
|-<br />
|OpenPGP || CCID<br />
|-<br />
|OATH || CCID<br />
|}<br />
<br />
All three interfaces can be independently enabled or disabled.<br />
The ykman program uses the term "manage connection modes" and uses<br />
OTP, FIDO, and CCID as selectors for which modes should be enabled.<br />
<br />
{{Note|The old U2F mode has been renamed and is now called FIDO in ykman 0.6.1 and later (released<br />
2018-04-16) https://developers.yubico.com/yubikey-manager/Release_Notes.html}}<br />
<br />
The set of enabled USB interfaces affects which applications on the<br />
key can be accessed. As an example, if only the HID interfaces are<br />
enabled, the applications dependent on the CCID interface are<br />
unavailable.<br />
<br />
Which application on the key is chosen is determined by the host<br />
application and is a combination of USB interface and an application<br />
selection mechanism. For example, if the host application wants to<br />
communicate with the PIV application on the key, it accesses the key<br />
using the CCID interface and using the protocols defined by CCID sends<br />
a 'select application' command to the key selecting the PIV application.<br />
<br />
==== Get enabled modes ====<br />
<br />
{{ic|ykman mode}} will tell you what modes are currently activated/enabled/available.<br />
This could output something like<br />
{{bc|Current connection mode is: OTP+U2F+CCID}}<br />
Meaning that currently the OTP, U2F and CCID subsystem of the key are enabled.<br />
<br />
==== Set the enabled modes ====<br />
<br />
{{ic|ykman mode <MODE>}} will allow you to define which modes should be activated/enabled/available. <br />
* {{ic|<MODE>}} can be a string, such as {{ic|OTP+U2F+CCID}}, or a shortened form {{ic|o+u+c}}.<br>With "+" you can combine multiple modes that you wish to be enabled.<br />
* {{ic|<MODE>}} can be a mode-number, which is one number that encodes several enabled modes (like flags) into one value.<br>The only valid modes when using numbers is 0 - 6 ([https://github.com/Yubico/yubikey-manager/blob/master/ykman/util.py#L94 see here]). The extra flags are not part of the mode in that sense, they just need to be set at the same time as the mode is set.<br />
<br />
Usually what you want is to make all functionality available (you will still need to potentially configure stuff, see functionality sections below for more details).<br />
In order to do so you can use:<br />
<br />
{{ic|ykman mode c+u+o}} or {{ic|ykman mode 6}}<br />
<br />
{{Note|Using the "80" mode-number or the corresponding {{ic|--touch-eject}} parameter of {{ic|ykman mode}} can only be used when the device is ''only'' in CCID mode (by running {{ic|ykman mode ccid --touch-eject}} for instance).<br />
<br />
Once the {{ic|--touch-eject}} flag is set, you should be able to eject/insert the smartcard by pressing the button. The LED should indicate if the card is inserted or not as well.<br />
}}<br />
<br />
{{Warning|But using the 80 mode-number or the corresponding {{ic|--touch-eject}} is not recommend as it would prevent you from using the U2F and OTP features of the YubiKey.}}<br />
<br />
{{Note|The often seen:<br />
<br />
{{ic|ykman mode c+u+o --touch-eject}} or {{ic|ykman mode 86}}<br />
<br />
will ignore the {{ic|--touch-eject}} and be identical to the above recommended {{ic|ykman mode 6}}.<br />
<br />
86 is not a valid mode. It might be a bug that the tool accepts higher values ([https://github.com/Yubico/yubikey-manager/issues/20#issuecomment-326496204 see here]).}}<br />
<br />
=== Two Slots ===<br />
<br />
Only if the OTP mode is activated (see Modes of the YubiKey below), the Yubikey provides 2 slots.<br />
<br />
If the transport mode OTP is enabled, the two YubiKey Slots, long press and short press, can be configured and used.<br />
<br />
==== Configuration of the slots ====<br />
<br />
These slots can have one of the following credentials configured: a [https://developers.yubico.com/OTP/ Yubico OTP] (which is what comes preconfigured in the short press slot on a new key), a static password, a challenge-response credential, an OATH-HOTP credential. All this functionality is found in the {{ic|ykman otp}} commands.<br />
<br />
{{Note|A slot has either a Yubico OTP or a challenge-response credential configured. More general: One, and only one, type of the above listed possible credential per slot.}}<br />
<br />
There are several flags that can be set during the configuration of the slots.<br />
These flags /cannot/ be read from the device once written. However, the behaviour of the device should change when the flags are set ;)<br />
<br />
{{Note|Actually most of (all of??) the parameters and details you use during configuration of the slots, cannot be read back, once written to the YubiKey.}}<br />
<br />
=== The LED ===<br />
<br />
The YubiKey has a small green LED able to communicate with you.<br />
Its message to you actually depends on the currently used [[#USB connection modes]] of your YubiKey.<br />
<br />
The possible messages are:<br />
* *steady on*: Press now, to allow access. (typically (TODO exclusively?) U2F mode)<br />
* *slow blinking*: Power/setting up/ready for use (TODO explain)<br />
* *rapid blinking*: Error, configuring driver (TODO explain)<br />
<br />
{{Note|If the CCID mode is turned on, then the LED of the key is always shortly flashing every two-three seconds once inserted.<br>You can turn the blinking off by disabling the CCID mode. This slow blinking just shows that the device has power, alternatively it shows a need for a button press. On Windows this behavior will typically stop once drivers are installed and it is ready for use. Mac and Linux systems will keep blinking; here [https://github.com/Yubico/yubikey-manager/issues/20#issuecomment-326496204 the best current workaround] to get the LED to blink less is to disable CCID.}}<br />
<br />
=== Initial configuration ===<br />
<br />
On a new YubiKey the Yubico OTP is preconfigured on slot 1. <br />
<br />
{{Warning|Before you overwrite your slot 1, please be aware that one is not able to reconfigure the same trust level [https://forum.yubico.com/viewtopic12ca.html?f=16&t=1960 see here]. Meaning:<br />
<br />
One could think that it is a good idea to reset configuration slot 1 to a new OTP. But then a "VV" prefix in your credentials must be used. Whereas the factory credentials on your Yubikey use a "CC" prefix. You can upload a "VV" credential using the Yubico personalization tool GUI or manually upload the new AES key to the [https://upload.yubico.com/ yubico.com website] in order to regain the same functionality than with the original factory configuration. VV credentials are not less secure than CC. However some services may only trust CC credentials as they believe that the user process is more prone to security vulnerabilities. This is because you could have malware on your machine or someone intercepting your key when sending it to the YubiCloud.<br />
}}<br />
<br />
=== Limitations of the passwords typed by YubiKey via USB-keyboard -- or "Why do my password look so weak ?" ===<br />
<br />
The YubiKey can type passwords (OTP or Static Password) for you by acting as USB keyboard and sending scan-codes like if you would type.<br />
<br />
A limitation of the YubiKey, however, prevents you from choosing characters that require a modifier key other than Shift.<br />
And in order for the YubiKey to work with all possible keyboard layouts (e.g. the {{ic|Z}} on a German keyboard has a different scan-code than the {{ic|Z}} on a US keyboard) it is necessary to limit the characters used by YubiKey passwords to the ModHex alphabet + Digits (0-9) (+ optionally "!" as the only available Symbol in static passwords).<br />
<br />
The 16 characters used in the ModHex alphabet are: {{ic|c,b,d,e,f,g,h,i,j,k,l,n,r,t,u,v}}. These characters share a property that makes them very valuable to a YubiKey: They use the same scan codes across a very large number of keyboard layouts. In other words, the scan code 0x06 maps to the character c for English, Swedish, German, French, and many others.<br />
<br />
[https://www.yubico.com/wp-content/uploads/2015/11/Yubico_WhitePaper_Static_Password_Function.pdf See here for full info]<br />
<br />
== One-time password ==<br />
<br />
=== Yubico OTP mode ===<br />
<br />
The Yubico OTP mode is AES symmetric key based. On a new YubiKey the Yubico OTP is preconfigured on slot 1. This initial AES symmetric key is stored in the YubiKey and the same AES key is already stored on the Yubico Authentication server. This allows validating against YubiCloud, meaning the use of Yubico OTP in combination with the Yubico Forum website for instance or on https://demo.yubico.com).<br />
<br />
The initial configuration and AES key stored in slot 1 can of course be overwritten.<br />
<br />
{{Warning|Please read [[#Initial configuration]] before you overwrite the intial configuration of slot 1 that your YubiKey comes shipped with.}}<br />
<br />
==== How does it work ====<br />
<br />
Yubikey's authentication protocol is based on [[Wikipedia:Symmetric_cryptography|symmetric cryptography]].<br />
More specifically, each YubiKey contains a 128-bit [[Wikipedia:Advanced_Encryption_Standard|AES]] key unique to that device.<br />
It is used to encrypt a token made of different fields such as the ID of the key, a counter, a random number, etc.<br />
The OTP is made from concatenating the ID of the key with this encrypted token.<br />
<br />
This OTP is sent to the target system to which we want to authenticate.<br />
This target system asks a validation server if the OTP is good.<br />
The validation server has a mapping of YubiKey IDs -> AES key.<br />
Using the key ID in the OTP, it can thus retrieve the AES key and decrypt the other part of the OTP.<br />
If it looks OK (plain-text ID and encrypted ID are the same, the counter is bigger than the last seen one to prevent [[wikipedia:Replay_attack|replay attacks]], then authentication is successful.<br />
<br />
The validation server sends that authentication status back to the target system, which grants access or not based on that response.<br />
<br />
==== Security risks ====<br />
<br />
===== AES key compromise =====<br />
<br />
As you can imagine, the AES key should be kept secret.<br />
It cannot be retrieved from the YubiKey itself (or it should not, at least not with software).<br />
It is present in the validation server though, so the security of this server is very important.<br />
<br />
===== Validation requests/responses tampering =====<br />
<br />
Since the target system relies on the ruling of the validation server, a trivial attack would be to impersonate the validation server.<br />
The target system thus needs to authenticate the validation server.<br />
2 methods are available :<br />
* '''HMAC''': This is also symmetric cryptography, the target server and validation server share a key that is used to sign requests and responses.<br />
* '''TLS''': Requests and responses travel via HTTP, so TLS (HTTPS) can be used to authenticate and encrypt the connection.<br />
<br />
==== YubiCloud and validation servers ====<br />
<br />
When you buy a YubiKey, it is preloaded with an AES key that is known only to Yubico.<br />
They will not even communicate it to you.<br />
Yubico provides a validation server with free unlimited access (YubiCloud).<br />
It also offers open-source implementations of the server.<br />
<br />
So you can either:<br />
* choose to use your YubiKey with its preloaded AES key and validate against Yubico's validation server ;<br />
* or load a new AES key in your YubiKey and run your own validation server.<br />
<br />
{{Note|To authenticate the Yubico validation server, you can:<br />
* '''with HMAC''': use https://upgrade.yubico.com/getapikey/ to get an HMAC key and ID<br />
* '''with HTTPS''': the validation server's certificate is signed by GoDaddy, and is thus trusted by default in Arch installs (at least if you have package ca-certificates)}}<br />
<br />
=== OATH-HOTP mode (RFC 4226) ===<br />
<br />
{{Expansion|Empty section.}}<br />
<br />
== Challenge-Response ==<br />
<br />
=== Function and Application of Challenge-Response ===<br />
This technique can be used to authenticate.<br />
<br />
A challenge is sent to the YubiKey and a response is (auto-magically) calculated and send back.<br />
This calculation needs a secret (e.g. an AES key in case of the Yubico OTP mode)<br />
The same challenge always results in the same response.<br />
Without the secret this calculation is not meant to be feasable. Even if in the possession of many challenge-response pairs.<br />
<br />
This can be used for:<br />
* true 2-factor (possession and knowledge) authentication:<br>If you combine the response (possession factor) with a password (knowledge factor) and to authenticate you need to present the triple (challenge,response, password) to 3rd party. In which case the challenge and the corresponding response can be (publicly) send to a 3rd party to authenticate the possession factor, by redoing basically the same (auto-magical) calculation. The needed secret needs to be shared with 3rd party to allow an authentication.<br />
<br />
* semi 2-factor (possession and knowledge) authentication:<br>The challenge can be public. Only with the possession of the YubiKey hardware the response can be generated. This can be used to create a "sort-of" 2-factor authentication (possession and knowledge): If you combine the response (possession factor) with a password (knowledge factor) and use the result for instance as passphrase for cryptsetup.<br />
<br />
This functionality will consume one slot. And it is used via API calls to the YubiKey. So you usually use some tool to communicate the challenge to your YubiKey and get back the response.<br />
<br />
There are two Challenge-Response modes:<br />
* Yubico OTP mode <br />
* HMAC-SHA1 mode<br />
<br />
=== Setup the slot ===<br />
<br />
{{Style|Duplicates {{man|1|ykpersonalize}}.}}<br />
<br />
In order to setup slot {{ic|2}} in challenge-response mode you may run:<br />
<br />
{{bc|ykpersonalize -v -2 -ochal-resp -ochal-hmac -ohmac-lt64 -oserial-api-visible -ochal-btn-trig}}<br />
<br />
Above arguments mean:<br />
* Verbose output ({{ic|-v}})<br />
* Use slot 2 ({{ic|-2}})<br />
* Set challenge-response mode ({{ic|-ochal-resp}})<br />
* Generate HMAC-SHA1 challenge responses ({{ic|-ochal-hmac}})<br />
* Calculate HMAC on less than 64 bytes input ({{ic|-ohmac-lt64}})<br />
* Allow Yubikey serial number to be read using an API call ({{ic|-oserial-api-visible}})<br />
* Require touching Yubikey before issue response ({{ic|-ochal-btn-trig}})<br />
<br />
You may also enable challenge-response mode using graphical interface through {{pkg|yubikey-personalization-gui}}<br />
<br />
{{Note|Before you overwrite the initial configuration of slot 1, please be aware of the '''Warning''' under [[#Initial configuration]].}}<br />
<br />
=== Use the slot - get a response for a challenge ===<br />
<br />
To use a Challenge-Response slot (no matter which mode):<br />
<br />
{{bc|ykchalresp -2 <CHALLENGE>}}<br />
<br />
== U2F ==<br />
<br />
{{Expansion}}<br />
<br />
=== Enabling U2F in the browser ===<br />
<br />
==== Chromium/Chrome ====<br />
<br />
[[Chromium/Tips and tricks#U2F authentication]]<br />
<br />
==== Firefox ====<br />
<br />
[[Firefox/Tweaks#Fido U2F authentication]]<br />
<br />
== CCID Smartcard ==<br />
<br />
CCID (Chip Card Interface Device) is a USB standard device class for use by USB devices that act as smart card readers or with security tokens that connect directly via USB, like the Yubikey. HID (Human Interface Device) and CCID are both USB device classes, i.e. they are in the same category of USB specifications. HID is a specification for computer peripherals, like keyboards. The Yubikey works like a USB (HID) keyboard when used in the OTP and U2F modes, but switches to the CCID protocol when using the PIV application, or as an OpenPGP device.<br />
<br />
CCID mode should be enabled by default on all YubiKeys shipped since November 2015 [https://www.yubico.com/support/knowledge-base/categories/articles/use-yubikey-yubikey-windows-hello-app/]. Enable at least the CCID mode. Please see [[#Set the enabled modes]].<br />
<br />
=== PIV ===<br />
<br />
Starting from the fourth generation devices, the Yubikeys contain a PIV (Personal Identity Verification) application on the chip. PIV is a US government standard (FIPS 201) that specifies how a token using RSA or ECC (Elliptic Curve Cryptography) is used for personal electronic identification. The distinguishing characteristic of a PIV token is that it is built to protect private keys and operate on them on-chip. A private key never leaves the token after it has been installed on it. Optionally, the private key can even be generated on-chip with the aid of an on-chip random number generator. If generated on-chip, the private key is never handled outside of the chip, and there is no way to recover it from the token. When using the PIV mechanism, the Yubikey functions as a CCID device.<br />
<br />
=== Use OpenPGP smartcard mode ===<br />
<br />
See [[GnuPG#Smartcards]]<br />
<br />
=== Using a YubiKey with SSH ===<br />
<br />
The following example describes how to use a YubiKey for [[SSH keys]]. A YubiKey with the PIV (Personal Identification Verification) application is required; this means you need a YubiKey NEO or YubiKey 4 or later.<br />
<br />
==== Generating a key pair on the YubiKey ====<br />
<br />
A private key and associated certificate need to be either generated on the YubiKey or imported to it. Install the {{Pkg|yubikey-manager}}<br />
package. Insert the YubiKey in a USB port and check that it is recognized:<br />
<br />
$ ykman list<br />
YubiKey 4 [OTP+FIDO+CCID] Serial: 1234567<br />
<br />
The following two commands ({{ic|generate-key}} and {{ic|generate-certificate}}) require providing the PIV application's 24-byte management key, if it has been changed from its default value (recommended). The examples below assume the shell variable {{ic|MK}} has been set in advance to the 48 character hex string representation of the management key. For example:<br />
<br />
$ MK=AB019982CA48BDC6776B1F9A0A3E129FDE0705D219AF0037<br />
<br />
Generate a 2048-bit RSA key pair on the YubiKey. The private key will be stored in key slot 9a on the YubiKey, and the public key will be<br />
written to the file {{ic|pubkey.pem}}.<br />
<br />
$ ykman piv generate-key -m $MK -a RSA2048 9a pubkey.pem<br />
<br />
Next, use the YubiKey to generate a self-signed certificate for the public key:<br />
<br />
$ ykman piv generate-certificate -m $MK -d 1826 -s "SSH Key" 9a pubkey.pem<br />
<br />
The Subject field in the certificate will be set to "SSH Key" with the {{ic|-s}} option. This field will be included in the prompt for PIN to help identify which key is used for authentication. The example command also specifies the {{ic|-d}} option to set the number of days until the certificate expires. If the {{ic|-d}} option is omitted, a default value of 365 days is used.<br />
<br />
Note that the last parameter in the {{ic|generate-key}} command is the file name where the public key is written to, whereas the last parameter in the {{ic|generate-certificate}} command specifies where the public key is read from. The certificate is constructed and signed on the YubiKey and stored alongside the private key; the command does not output the certificate.<br />
<br />
At this point the YubiKey is ready for authenticating to a SSH server. For this to happen, some additional configuration on both the client and the server is required.<br />
<br />
==== Client configuration ====<br />
<br />
The standard API used to communicate with cryptographic tokens is defined by [[wikipedia:PKCS_11|PKCS#11]].<br />
Install the {{Pkg|opensc}} package which provides this API in the form of the shared library {{ic|/usr/lib/opensc-pkcs11.so}}. The ssh client should be configured to use this library with the directive PKCS11Provider in {{ic|~/.ssh/config}}:<br />
<br />
{{hc|~/.ssh/config|PKCS11Provider /usr/lib/opensc-pkcs11.so}}<br />
<br />
==== Public key conversion ====<br />
<br />
The {{ic|pubkey.pem}} file contains the public key in PEM (Privacy Enhanced Mail) format. OpenSSH uses a different format defined in RFC 4253,<br />
section 6.6, so the PEM formatted key should be converted to the format OpenSSH understands. This can be done using ''ssh-keygen'':<br />
<br />
$ ssh-keygen -i -m PKCS8 -f pubkey.pem > pubkey.txt<br />
<br />
This command uses the import ({{ic|-i}}) function of the ''ssh-keygen'' program, specifies PKCS8 as the input file format ({{ic|-m}}), and reads the input from the ({{ic|-f}}) file {{ic|pubkey.pem}}. The converted key is written on standard output, which is the example is redirected to the file {{ic|pubkey.txt}}.<br />
<br />
The converted public key should now be copied to the remote server as described in [[SSH keys#Copying the public key to the remote server]].<br />
<br />
==== Initiating an SSH session with the YubiKey ====<br />
<br />
To authenticate a SSH connection using the YubiKey, just use ''ssh'' normally. You will be prompted for the PIN instead of a password:<br />
<br />
$ ssh remote<br />
Enter PIN for 'SSH Key' <br />
[user@remote ~]$ <br />
<br />
==== Using ssh-agent to cache the PIN ====<br />
<br />
ssh-agent (see [[SSH keys#SSH agents]]) can also be used with the PKCS#11 library; in this case the PIN code is cached instead of the private key.<br />
<br />
$ ssh-add -s /usr/lib/pkcs11/opensc-pkcs11.so<br />
<br />
As long as the PIN is cached in by the agent, the cached value is used and the user is not prompted for it.<br />
<br />
==== Further reading ====<br />
<br />
The default PIN code of the PIV application on the YubiKey is {{ic|123456}}; you may want to change it. The YubiKey also requires a 24-byte management key for administrative functions like key generation. If the management key has been changed from its default value, the new value needs to be specified using the -m option on the command line for certain commands. See [https://developers.yubico.com/PIV/ What is PIV?]<br />
<br />
== Tips and tricks ==<br />
<br />
=== YubiKey and LUKS encrypted partition/disk ===<br />
<br />
YubiKey can be used to strengthen the security of your [[LUKS]] encrypted partition/disk.<br />
<br />
One way to achieve it is to use a Challenge-Response mode for creating strong LUKS passphrases. [https://github.com/agherzan/yubikey-full-disk-encryption yubikey-full-disk-encryption] is a robust and comfortable to use implementation of an [[initramfs]] hook and on-demand scripts to create/open LUKS encrypted partitions/disks using a stored or manually provided challenge.<br />
<br />
Another way of using YubiKey for full disk encryption is to utilize its OpenPGP applet to decrypt the LUKS keyfile during boot. [https://github.com/fuhry/initramfs-scencrypt initramfs-scencrypt] is a set of hooks for initramfs that automate this process.<br />
<br />
=== Yubikey and KeePass ===<br />
<br />
{{Style|Duplicates [[KeePass]].}}<br />
<br />
Yubikey can be integrated with [[KeePass]] using [[KeePass#Yubikey|plugins]].<br />
<br />
For a native open-source implementation of KeePass have a look at:<br />
<br />
==== keepassx2 ====<br />
<br />
{{AUR|keepassx2}} ([https://keepassx.org/ see keepassx.org]) a keepass QT FOSS reimplementation, extremely stable and available for Windows, MacOSX and Linux.<br />
<br />
==== KeePassXC ====<br />
<br />
{{Pkg|keepassxc}} ([https://keepassxc.org/ see keepassxc.org]) a KeePassX fork that integrated YubiKey into KeePassX v2.<br>The integration covers Challenge-Response as security factor to open the database, but also the generation of OTP using the YubiKey.<br />
<br />
In order to have a KeePassXC database work on Android (using the [https://play.google.com/store/apps/details?id=keepass2android.keepass2android Keepass2Android app]), you need to use version 1.06 of the app. You also need to save the database file in the KDBX 4 format, since Keepass2Android do not support the KDBX 3 format.<br />
<br />
YubiKey support in Keepass2Android (which is compatible with KeePassXC) is tracked [https://github.com/PhilippC/keepass2android/issues/4 on GitHub].<br />
<br />
=== Two-factor authentication with SSH ===<br />
<br />
{{Note|See also: https://developers.yubico.com/yubico-pam/Yubikey_and_SSH_via_PAM.html}}<br />
<br />
This details how to use a Yubikey to have [[wikipedia:Two-factor_authentication|two-factor authentication]] with SSH, that is, to use both a password and a Yubikey-generated OTP.<br />
<br />
==== Prerequisites ====<br />
<br />
Install {{Pkg|yubico-pam}}.<br />
<br />
{{Note|If you are configuring a distant server to use Yubikey, you should open at least one additional, rescue SSH session, so that you are not locked out of your server if the configuration does not work and you exit your main session inadvertently}}<br />
<br />
{{Note|The following assumes you are using the default Yubico servers. See the [https://github.com/Yubico/yubico-pam yubico-pam documentation] for options relevant to using your own server.}}<br />
<br />
==== Configuration ====<br />
<br />
===== Authorization Mapping Files =====<br />
<br />
A mapping must be made between the YubiKey token ID and the user ID it is<br />
attached to. There are two ways to do this, either centrally in one file, or<br />
individually, where users can create the mapping in their home directories.<br />
If the central authorization mapping file is being used, user home directory<br />
mappings will not be used and vice versa.<br />
<br />
====== Central authorization mapping ======<br />
<br />
Create a file {{ic|/etc/yubico/authorized_yubikeys}}, the file must contain a user name and the<br />
Yubikey token ID separated by colons (same format as the passwd file) for<br />
each user you want to allow onto the system using a Yubikey.<br />
<br />
The mappings should look like this, one per line:<br />
<br />
<first user name>:<Yubikey token ID1>:<Yubikey token ID2>:...<br />
<second user name>:<Yubikey token ID3>:<Yubikey token ID4>:...<br />
<br />
You can specify multiple key tokens to correspond to one user, but only one is required.<br />
<br />
====== Per-user authorization mapping ======<br />
<br />
Each user creates a {{ic|~/.yubico/authorized_yubikeys}} file inside of their home<br />
directory and places the mapping in that file, the file must have only one<br />
line:<br />
<br />
<user name>:<Yubikey token ID1>:<Yubikey token ID2><br />
<br />
This is much the same concept as the SSH authorized_keys file.<br />
<br />
Note that this file must be readable by the {{ic|pam_yubico}} module when the user is authenticated, otherwise login will fail. If this is not possible or desired, use the global mapping file instead.<br />
<br />
====== Obtaining the YubiKey token ID (a.k.a. public ID) ======<br />
<br />
You can obtain the YubiKey token ID in several ways. One is by<br />
removing the last 32 characters of any OTP (One Time Password)<br />
generated with your YubiKey. Another is by using the<br />
[http://demo.yubico.com/php-yubico/Modhex_Calculator.php modhex calculator].<br />
<br />
Enter your YubiKey OTP and convert it, your Yubikey token ID is 12<br />
characters and listed as:<br />
<br />
Modhex encoded: XXXXXXX<br />
<br />
===== PAM configuration =====<br />
<br />
Having set up the {{ic|pam_yubico}} module, you next need to tell PAM to use it when logging in via SSH. There are several ways of doing this.<br />
<br />
====== The default way ======<br />
<br />
Obtain HMAC credentials from Yubico as described in [[#YubiCloud and validation servers]]. You will receive a Client ID and a secret key.<br />
<br />
Add one of the two following lines to the beginnning of {{ic|/etc/pam.d/sshd}}:<br />
<br />
auth required pam_yubico.so id=CLIENTID authfile=/etc/yubico/authorized_yubikeys<br />
<br />
if you are using a central authorization mapping file, or<br />
<br />
auth required pam_yubico.so id=CLIENTID<br />
<br />
if you are using per-user authorization mapping, where {{ic|CLIENTID}}} is your Client ID. This method utilizes your ID and the server's certificate to authenticate the connection.<br />
<br />
{{Note|This will authenticate via Yubico's free YubiCloud servers. If you want to use a different server, add it via the {{ic|urllist}} parameter.}}<br />
<br />
====== Using pure HMAC to authenticate the validation server ======<br />
<br />
Add {{ic|key}} to the above lines in {{ic|/etc/pam.d/sshd}}:<br />
<br />
auth required pam_yubico.so id=CLIENTID key=SECRETKEY ...<br />
<br />
where {{ic|CLIENTID}} and {{ic|SECRETKEY}} are your HMAC ID and key.<br />
<br />
You should also disallow unprivileged users to read the file to prevent them from seeing the HMAC credentials:<br />
# chmod o-r /etc/pam.d/sshd<br />
<br />
{{Note|HMAC credentials should be unique to a single target server. That way, if an attacker finds them, he will not be able to craft responses to authenticate to other target servers you own}}<br />
<br />
====== Using pure HTTPS to authenticate the validation server ======<br />
<br />
{{Warning|While this "old" method of using a dummy id still works, it is unknown how secure and/or future-proof it is, as Yubico no longer describes it in their documentation. Proceed at your own risk. At the very least you should ensure that only HTTPS servers with valid certificates are used for authentication.}}<br />
<br />
If you do not want to use HMAC credentials from Yubico, it is still possible to authenticate via the Yubico server by setting {{ic|1=CLIENTID=1}} instead of your own ID. Although {{ic|pam_yubico}}'s default server uses HTTPS already, for security reasons you should specify it manually via the {{ic|urllist}} parameter, as the servers certificate is the only way in which the connection is authenticated. You can find the keyserver URL by adding the {{ic|debug}} parameter to the {{ic|auth}} line.<br />
<br />
===== SSHD configuration =====<br />
<br />
You should check that {{ic|/etc/ssh/sshd_config}} contains these lines and that they are not commented. The {{ic|sshd_config}} shipped with {{pkg|openssh}} has these set correctly by default.<br />
ChallengeResponseAuthentication no<br />
UsePAM yes<br />
<br />
==== That is it! ====<br />
<br />
You should not need to restart anything if you did not change the SSHD config file.<br />
<br />
To log in, at the {{ic|Password:}} prompt of SSH, you have to type your password '''without pressing enter''' and touch the Yubikey's button.<br />
The Yubikey should send a return at the end of the OTP so you do not need to touch the enter key at all.<br />
<br />
You can display information about the login data generated by {{ic|pam_yubico}} by adding the {{ic|debug}} option to the auth line in{{ic|/etc/pam.d/sshd}}. However, if you are using a central authorization file, you should remove that option once finished testing, as it causes {{ic|pam_yubico}} to display the entire content of the central file to every user who logs in using a Yubikey.<br />
<br />
==== Explanation ====<br />
<br />
This works because the prompt is {{ic|pam_yubico.so}}'s one, since this module is before {{ic|pam_unix.so}}, which normally does basic password authentication.<br />
So, you are giving a string that is the concatenation of your password and the OTP to {{ic|pam_yubico.so}}.<br />
Since the OTPs have a fixed length (let us call this size N), it just has to get the last N characters to retrieve the OTP, and it assumes that the other characters at the start are the password.<br />
It tries to validate the OTP, and in case of success, sends the password to the next PAM module. In Archlinux' default PAM stack, the authenticator {{ic|pam_unix.so}} is instructed to try receiving a password from the previous module with {{ic|try_first_pass}}, so it automatically uses the password sent by {{ic|pam_yubico.so}}.<br />
<br />
=== Executing actions on insertion/removal of yubikey device ===<br />
<br />
For example, you want to perform an action when you pull your yubikey out of the USB slot, create {{ic|/etc/udev/rules.d/80-yubikey-actions.rules}} and add the following contents:<br />
ACTION=="remove", ENV{ID_MODEL}=="Yubikey_4_OTP+U2F+CCID", ENV{ID_VENDOR_ID}=="1050", ENV{ID_MODEL_ID}=="0407", RUN+="/usr/local/bin/script args"<br />
<br />
Please note, that this example is for the yubikey 4, and you will have to look at the output of lsusb to get the vendor and model ID's, along with the description of the device. Of course, to execute a script on insertion, you would change the action to 'add' instead of remove.<br />
<br />
== Maintenance / Upgrades ==<br />
<br />
=== Installing the OATH Applet for a YubiKey NEO ===<br />
<br />
These steps will allow you to install the OATH applet onto your YubiKey NEO. This allows the use of Yubico Authenticator in the Google Play Store.<br />
{{Note|1=These steps are only for NEOs with a firmware version <= 3.1.2. The current generation NEOs (with U2F) come with the OpenPGP applet already installed)}}<br />
<br />
==== Configure the NEO as a CCID Device ====<br />
<br />
# Install {{pkg|yubikey-personalization-gui}} ({{AUR|yubikey-personalization-gui-git}}).<br />
# Add the udev rules and reboot so you can manage the YubiKey without needing to be root<br />
# Run {{ic|ykpersonalize -m82}}, enter {{ic|y}}, and hit enter.<br />
<br />
==== Install the Applet ====<br />
<br />
# Install {{AUR|gpshell}}, {{AUR|gppcscconnectionplugin}}, {{AUR|globalplatform}}, and {{Pkg|pcsclite}}.<br />
# [[Start]] {{ic|pcscd.service}}.<br />
# Download the most recent CAP file from the [http://opensource.yubico.com/ykneo-oath/releases.html ykneo-oath] site.<br />
# Download {{ic|gpinstall.txt}} from [https://github.com/Yubico/ykneo-oath/blob/master/gpinstall.txt GitHub].<br />
# Edit the line in gpinstall.txt beginning with {{ic|install -file}} to reflect the path where the CAP file is located.<br />
# Open a terminal and run {{ic| gpshell <location of gpinstall.txt>}}<br />
# Ideally, a bunch of text will scroll by and it ends saying something like<br />
{{ bc | Command --> 80E88013D7C000C400BE00C700CA00CA00B400BE00CE00D200D500D700B000DB00C700DF00BEFFFF00BE00E400AC00AE00AE00DB00E700A<br />
A00EA00ED00ED00ED00BE00EF00F100F400F100F700FA00FF00BE00F700AA01010103010700CA00C400B400AA00F700B400AA00B600C7010C<br />
010C00AA0140012001B0056810B0013005600000056810E0011006B4B44304B44404B44106B44B4405B443400343B002410636810E06B4B44<br />
407326810B004B43103441003334002B102B404B3B403BB4003B440076820A4100221024405B4341008B44600000231066820A100<br />
Wrapped command --> 84E88013DFC000C400BE00C700CA00CA00B400BE00CE00D200D500D700B000DB00C700DF00BEFFFF00BE00E400AC00AE00AE00DB00E700A<br />
A00EA00ED00ED00ED00BE00EF00F100F400F100F700FA00FF00BE00F700AA01010103010700CA00C400B400AA00F700B400AA00B600C7010C<br />
010C00AA0140012001B0056810B0013005600000056810E0011006B4B44304B44404B44106B44B4405B443400343B002410636810E06B4B44<br />
407326810B004B43103441003334002B102B404B3B403BB4003B440076820A4100221024405B4341008B44600000231066820A15D848CB77<br />
27D0EDA00<br />
Response <-- 009000<br />
Command --> 80E60C002107A000000527210108A00000052721010108A000000527210101010003C901000000<br />
Wrapped command --> 84E60C002907A000000527210108A00000052721010108A000000527210101010003C9010000B4648127914A4C7C00<br />
Response <-- 009000<br />
card_disconnect<br />
release_context}}<br />
# Unplug the NEO and try it with the Yubico Authenticator app<br />
<br />
==== (Optional) Install the Yubico Authenticator Desktop client ====<br />
<br />
You can get the desktop version of the Yubico Authenticator by installing {{AUR|yubico-yubioath-desktop}}{{Broken package link|package not found}} or {{AUR|yubico-yubioath-desktop-git}}.<br />
<br />
While {{ic|pcscd.service}} is running, run {{ic|yubioath-gui}} and insert your Yubikey when prompted.<br />
<br />
== Troubleshooting ==<br />
<br />
Restart, especially if you have completed updates since your Yubikey last worked. Do this even if some functions appear to be functioning.<br />
<br />
=== YubiKey not acting as HID device ===<br />
Add udev rule as described in [https://michaelheap.com/yubikey-on-arch/ this article]:<br />
<br />
{{hc|/etc/udev/rules.d/10-security-key.rules|2=<br />
KERNEL=="hidraw*", SUBSYSTEM=="hidraw", MODE="0664", GROUP="users", ATTRS{idVendor}=="2581", ATTRS{idProduct}=="f1d0"<br />
}}<br />
<br />
Run {{ic|udevadm trigger}} afterwards.<br />
<br />
You may also need to [[install]] the package {{pkg|libu2f-host}} if you want support in chrome.<br />
<br />
=== ykman fails to connect to the YubiKey ===<br />
<br />
If the manager fails to connect to the YubiKey, make sure you have started {{ic|pcscd.service}} or {{ic|pcscd.socket}}.<br />
<br />
=== YubiKey fails to bind within a guest VM ===<br />
<br />
Assuming the Yubikey is available to the guest, the issue results from a driver binding to the device on the host. To unbind the device, the bus and port information is needed from {{ic|dmesg}} on the host:<br />
<br />
$ dmesg | grep -B1 Yubico | tail -n 2 | head -n 1 | sed -E 's/^\<nowiki>[[^]]</nowiki>+\] usb (<nowiki>[^:]</nowiki>*):.*/\1/'<br />
<br />
The resulting USB id should be of the form {{ic|X-Y.Z}} or {{ic|X-Y}}. Then, on the host, use {{ic|find}} to search {{ic|/sys/bus/usb/drivers}} for which driver the Yubikey is binded to (e.g. {{ic|usbhid}} or {{ic|usbfs}}).<br />
<br />
$ find /sys/bus/usb/drivers -name "*X-Y.Z*"<br />
<br />
To unbind the device, use the result from the previous command (i.e. {{ic|/sys/bus/usb/drivers/<DRIVER>/X-Y.Z:1.0}}):<br />
<br />
# echo 'X-Y.Z:1.0' > /sys/bus/usb/drivers/<DRIVER>/unbind<br />
<br />
=== Error: [key] could not be locally signed or gpg: No default secret key: No public key ===<br />
<br />
Occurs when attempting to sign keys on a non-standard keyring while a YubiKey is plugged in, e.g. as [[Pacman/Package_signing|Pacman]] does in {{ic|pacman-key --populate archlinux}}. The solution is to remove the offending YubiKey and start over.</div>Hardfalconhttps://wiki.archlinux.org/index.php?title=Ganglia&diff=587573Ganglia2019-11-02T03:31:33Z<p>Hardfalcon: Updated link to Ganglia wiki</p>
<hr />
<div>[[Category:System monitors]]<br />
[[ja:Ganglia]]<br />
[http://ganglia.sourceforge.net/ Ganglia] is a scalable distributed system monitor tool for high-performance computing systems such as clusters and grids. It allows the user to remotely view live or historical statistics (such as CPU load averages or network utilization) for all machines that are being monitored.<br />
<br />
Ganglia is available as the {{AUR|ganglia}} package on the [[AUR]], along with the web frontend {{AUR|ganglia-web}}. There is also a reduced-dependency version named {{AUR|ganglia-minimal}}, which would be appropriate on boxes where you don't require {{ic|gmetad}} and want to avoid pulling in {{ic|rrdtool}} as a dependency, which would in turn pull in Cairo and Mesa.<br />
<br />
The [https://github.com/ganglia/monitor-core/wiki Ganglia Wiki] contains all the information you need to get started with Ganglia.<br />
<br />
== Ganglia Web Interface ==<br />
<br />
The ganglia web frontend is available as the {{AUR|ganglia-web}} package on the AUR.<br />
<br />
You will also need a [[web server]] with a working [[PHP]] setup. The following sections include some example setups.<br />
<br />
Make sure that the {{ic|open_basedir}} setting in your {{ic|/etc/php/php.ini}} includes {{ic|/tmp}}, {{ic|/usr/share/webapps}} and {{ic|/var/lib/ganglia}}.<br />
<br />
=== Nginx with php-fpm ===<br />
<br />
{{Style|See [[Help:Style#Package management instructions]] and [[Help:Style#systemd units operations]].}}<br />
<br />
Firstly, install the required packages:<br />
<br />
pacman -S nginx php-fpm<br />
<br />
Secondly, read the [[Nginx]] article. Note its [[Nginx#FastCGI]] and subsequent php-fpm sections. [[Nginx#Adding to main configuration]] details a minimum {{ic|nginx.conf}} to use. <br />
<br />
An older minimal configuration for nginx would be something like this:<br />
{{hc|/etc/nginx/nginx.conf|<br />
events {<br />
worker_connections 1024;<br />
}<br />
<br />
http {<br />
include mime.types;<br />
default_type application/octet-stream;<br />
<br />
upstream php {<br />
server unix:/run/php-fpm/php-fpm.sock;<br />
}<br />
<br />
server {<br />
listen 80 default_server;<br />
<br />
root /usr/share/webapps;<br />
index index.php;<br />
<br />
location ~ \.php$ {<br />
fastcgi_pass php;<br />
include fastcgi.conf;<br />
}<br />
}<br />
}<br />
}}<br />
<br />
Then start all required services:<br />
<br />
systemctl start gmetad gmond php-fpm nginx<br />
<br />
Go to http://localhost/ganglia and check that your setup is working.<br />
<br />
== Troubleshooting ==<br />
<br />
=== Issues with IP-address binding or undesirable hostnames ===<br />
<br />
If {{ic|1= bind_hostname = yes}} in the {{ic|udp_send_channel}} section of {{ic|gmond.conf}}, the {{ic|gmond}} daemon will determine which '''IP''' to bind to (and report in the XML data) by determining the IP address of the default hostname. You should be able to replicate this behaviour with one of these commands:<br />
<br />
{{bc|<br />
$ hostname -i<br />
$ host $(hostname)<br />
}}<br />
<br />
The '''hostname''' to report is determined by asking the system to look up a hostname for the chosen IP address, in order to ensure the hostname is that by which other machines on the network identify the monitored machine:<br />
<br />
{{bc|<br />
$ host <ip-address><br />
}}<br />
<br />
The hostname listed at the top of the list is the one that will be reported by {{ic|gmond}}, and will appear in the web UI. You can influence the returned hostname by modifying your {{ic|/etc/hosts}} or {{ic|/etc/nsswitch.conf}} files. In particular, watch out for placing {{ic|myhostname}} before {{ic|dns}} on the {{ic|hosts}} line in {{ic|/etc/nsswitch.conf}}. This will cause {{ic|gmond}} to attempt to bind to a UDP port on 127.0.0.1, and it will fail to load.<br />
<br />
If you're not able to achieve the desired behaviour, the hostname can be overridden in the {{ic|gmond.conf}} file by adding the following lines to the {{ic|globals}} section:<br />
<br />
{{bc|1=<br />
globals {<br />
...<br />
override_hostname = myhostname.mydomain<br />
override_ip = 127.0.0.2<br />
}<br />
}}<br />
<br />
== References ==<br />
* E-mail exchange explaining IP and Hostname lookup: http://www.mail-archive.com/ganglia-general@lists.sourceforge.net/msg01885.html</div>Hardfalconhttps://wiki.archlinux.org/index.php?title=Microcode&diff=584877Microcode2019-10-09T05:50:57Z<p>Hardfalcon: /* systemd-boot */ The factual accuracy of the section about single-file EFI kernel images used for secure boot is not disputed</p>
<hr />
<div>[[Category:CPU]]<br />
[[Category:Security]]<br />
[[de:Microcode]]<br />
[[es:Microcode]]<br />
[[ja:マイクロコード]]<br />
[[ru:Microcode]]<br />
[[zh-hans:Microcode]]<br />
Processor manufacturers release stability and security updates to the processor [[Wikipedia:Microcode|microcode]]. These updates provide bug fixes that can be critical to the stability of your system. Without them, you may experience spurious crashes or unexpected system halts that can be difficult to track down.<br />
<br />
All users with an AMD or Intel CPU should install the microcode updates to ensure system stability.<br />
<br />
Microcode updates are usually shipped with the motherboard's firmware and applied during firmware initialization. Since OEMs might not release firmware updates in a timely fashion and old systems do not get new firmware updates at all, the ability to apply CPU microcode updates during boot was added to the Linux kernel. [https://www.kernel.org/doc/Documentation/x86/microcode.txt The Linux microcode loader] supports three loading methods:<br />
<br />
# '''Early loading''' updates the microcode very early during boot, before the initramfs stage, so it is the preferred method. This is mandatory for CPUs with severe hardware bugs, like the Intel Haswell and Broadwell processor families.<br />
# '''Late loading''' updates the microcode after booting which could be too late since the CPU might have already tried to use a bugged instruction set. Even if already using early loading, late loading can still be used to apply a newer microcode update without needing to reboot.<br />
# '''Built-in microcode''' can be compiled into the kernel that is then applied by the early loader.<br />
<br />
== Early loading ==<br />
<br />
Microcode must be loaded by the [[boot loader]]. Because of the wide variability in users' early-boot configuration, microcode updates may not be triggered automatically by Arch's default configuration. Many AUR kernels have followed the path of the official Arch [[kernels]] in this regard.<br />
<br />
These updates must be enabled by adding {{ic|/boot/amd-ucode.img}} or {{ic|/boot/intel-ucode.img}} as the '''first initrd in the bootloader config file'''. This is in addition to the normal initrd file. See below for instructions for common bootloaders.<br />
<br />
{{Note|In the following sections replace {{ic|''cpu_manufacturer''}} with your CPU manufacturer, i.e. {{ic|amd}} or {{ic|intel}}.}}<br />
<br />
{{Tip|For [[Installing Arch Linux on a USB key|Arch Linux on a removable drive]] add both microcode files as {{ic|initrd}} to the boot loader configuration. Their order does not matter as long as they both are specified before the real initramfs image.}}<br />
<br />
=== Installation ===<br />
<br />
For AMD processors, [[install]] the {{Pkg|amd-ucode}} package.<br />
<br />
For Intel processors, [[install]] the {{Pkg|intel-ucode}} package.<br />
<br />
If your Arch installation is [[Installing Arch Linux on a USB key|on a removable drive]] that needs to have microcode for both manufacturer processors, install both packages.<br />
<br />
=== Configuration ===<br />
<br />
==== Enabling early microcode loading in custom kernels ====<br />
<br />
In order for early loading to work in custom kernels, "CPU microcode loading support" needs to be compiled into the kernel, '''not''' compiled as a module. This will enable the "Early load microcode" prompt which should be set to {{ic|Y}}.<br />
<br />
CONFIG_BLK_DEV_INITRD=Y<br />
CONFIG_MICROCODE=y<br />
CONFIG_MICROCODE_INTEL=Y<br />
CONFIG_MICROCODE_AMD=y<br />
<br />
==== GRUB ====<br />
<br />
''grub-mkconfig'' will automatically detect the microcode update and configure [[GRUB]] appropriately. After installing the microcode package, regenerate the GRUB config to activate loading the microcode update by running:<br />
<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
Alternatively, users that manage their GRUB config file manually can add {{ic|/boot/''cpu_manufacturer''-ucode.img}} (or {{ic|/''cpu_manufacturer''-ucode.img}} if {{ic|/boot}} is a separate partition) as follows:<br />
<br />
{{hc|/boot/grub/grub.cfg|<br />
...<br />
echo 'Loading initial ramdisk'<br />
initrd '''/boot/''cpu_manufacturer''-ucode.img''' /boot/initramfs-linux.img<br />
...<br />
}}<br />
<br />
Repeat it for each menu entry.<br />
<br />
==== systemd-boot ====<br />
<br />
Use the {{ic|initrd}} option to load the microcode, before the initial ramdisk, as follows:<br />
<br />
{{hc|/boot/loader/entries/''entry''.conf|<br />
title Arch Linux<br />
linux /vmlinuz-linux<br />
'''initrd /''cpu_manufacturer''-ucode.img'''<br />
initrd /initramfs-linux.img<br />
...<br />
}}<br />
<br />
The latest microcode {{ic|''cpu_manufacturer''-ucode.img}} must be available at boot time in your [[EFI system partition]] (ESP). The ESP must be mounted as {{ic|/boot}} in order to have the microcode updated every time {{Pkg|amd-ucode}} or {{Pkg|intel-ucode}} is updated. Otherwise, copy {{ic|/boot/''cpu_manufacturer''-ucode.img}} to your ESP at every update of the microcode package.<br />
<br />
For [[systemd-boot#Preparing kernels for /EFI/Linux|kernels that have been generated as a single file]] containing all initrd, cmdline and kernel, first generate the initrd to integrate by creating a new one as follows: <br />
<br />
{{bc|1=<br />
cat /boot/''cpu_manufacturer''-ucode.img /boot/initramfs-linux.img > my_new_initrd<br />
objcopy ... --add-section .initrd=my_new_initrd <br />
}}<br />
<br />
==== EFISTUB ====<br />
<br />
Append two {{ic|1=initrd=}} options:<br />
<br />
'''initrd=/''cpu_manufacturer''-ucode.img''' initrd=/initramfs-linux.img<br />
<br />
==== rEFInd ====<br />
<br />
Edit boot options in {{ic|/boot/refind_linux.conf}} and add {{ic|1=initrd=/boot/''cpu_manufacturer''-ucode.img}} (or {{ic|1=initrd=/''cpu_manufacturer''-ucode.img}} if {{ic|/boot}} is a separate partition) as the first initramfs. For example:<br />
<br />
"Boot using default options" "root=PARTUUID=''XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX'' rw add_efi_memmap '''initrd=/boot/''cpu_manufacturer''-ucode.img''' initrd=/boot/initramfs-%v.img"<br />
<br />
Users employing [[rEFInd#Manual boot stanzas|manual stanzas]] in {{ic|''esp''/EFI/refind/refind.conf}} to define the kernels should simply add {{ic|1=initrd=/boot/''cpu_manufacturer''-ucode.img}} (or {{ic|/''cpu_manufacturer''-ucode.img}} if {{ic|/boot}} is a separate partition) as required to the options line, and not in the main part of the stanza. E.g.:<br />
<br />
options "root=PARTUUID=''XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX'' rw add_efi_memmap '''initrd=/boot/''cpu_manufacturer''-ucode.img'''"<br />
<br />
==== Syslinux ====<br />
<br />
{{Note|There must be no spaces between the {{ic|''cpu_manufacturer''-ucode.img}} and {{ic|initramfs-linux.img}} initrd files. The {{ic|INITRD}} line must be exactly as illustrated below.}}<br />
<br />
Multiple initrd's can be separated by commas in {{ic|/boot/syslinux/syslinux.cfg}}:<br />
<br />
LABEL arch<br />
MENU LABEL Arch Linux<br />
LINUX ../vmlinuz-linux<br />
INITRD '''../''cpu_manufacturer''-ucode.img''',../initramfs-linux.img<br />
...<br />
<br />
==== LILO ====<br />
<br />
[[LILO]] and potentially other old bootloaders do not support multiple initrd images. In that case, {{ic|''cpu_manufacturer''-ucode.img}} and {{ic|initramfs-linux.img}} will have to be merged into one image.<br />
<br />
{{Warning|The merged image must be recreated after each kernel update!}}<br />
<br />
{{Note|The order is important. The original image {{ic|initramfs-linux.img}} must be placed '''after''' {{ic|''cpu_manufacturer''-ucode.img}} in the resulting image.}}<br />
<br />
To merge both images into one image named {{ic|initramfs-merged.img}}, the following command can be used:<br />
<br />
# cat /boot/''cpu_manufacturer''-ucode.img /boot/initramfs-linux.img > /boot/initramfs-merged.img<br />
<br />
Now, edit {{ic|/etc/lilo.conf}} to load the new image.<br />
<br />
...<br />
initrd=/boot/initramfs-merged.img<br />
...<br />
<br />
And run {{ic|lilo}} as root:<br />
<br />
# lilo<br />
<br />
== Late loading ==<br />
<br />
Late loading of microcode updates happens after the system has booted. It uses files in {{ic|/usr/lib/firmware/amd-ucode/}} and {{ic|/usr/lib/firmware/intel-ucode/}}.<br />
<br />
For AMD processors the microcode update files are provided by {{Pkg|linux-firmware}}.<br />
<br />
For Intel processors no package provides the microcode update files ({{Bug|59841}}). To use late loading you need to manually extract {{ic|intel-ucode/}} from Intel's provided archive.<br />
<br />
=== Enabling late microcode updates ===<br />
<br />
Unlike early loading, late loading of microcode updates on Arch Linux are enabled by default using {{ic|/usr/lib/tmpfiles.d/linux-firmware.conf}}. After boot the file gets parsed by {{man|8|systemd-tmpfiles-setup.service}} and CPU microcode gets updated.<br />
<br />
To manually reload the microcode, e.g. after updating the microcode files in {{ic|/usr/lib/firmware/amd-ucode/}} or {{ic|/usr/lib/firmware/intel-ucode/}}, run:<br />
<br />
# echo 1 > /sys/devices/system/cpu/microcode/reload<br />
<br />
This allows to apply newer microcode updates without rebooting the system. For {{Pkg|linux-firmware}} you can automate it with a [[pacman hook]], e.g.:<br />
<br />
{{hc|/etc/pacman.d/hooks/microcode_reload.hook|2=<br />
[Trigger]<br />
Operation = Install<br />
Operation = Upgrade<br />
Operation = Remove<br />
Type = File<br />
Target = usr/lib/firmware/amd-ucode/*<br />
<br />
[Action]<br />
Description = Applying CPU microcode updates...<br />
When = PostTransaction<br />
Depends = sh<br />
Exec = /bin/sh -c 'echo 1 > /sys/devices/system/cpu/microcode/reload'<br />
}}<br />
<br />
=== Disabling late microcode updates ===<br />
<br />
For AMD systems the CPU microcode will get updated even if {{Pkg|amd-ucode}} is not installed since the files in {{ic|/usr/lib/firmware/amd-ucode/}} are provided by the {{Pkg|linux-firmware}} package ({{Bug|59840}}).<br />
<br />
For [[virtual machine]]s and [[Wikipedia:Container (virtualization)|containers]] ({{Bug|46591}}) it is not possible to update the CPU microcode, so you may want to disable microcode updates. To do so, you must override the [[tmpfile]] {{ic|/usr/lib/tmpfiles.d/linux-firmware.conf}} that is provided by {{Pkg|linux-firmware}}. It can be done by creating a file with the same filename in {{ic|/etc/tmpfiles.d/}}:<br />
<br />
# ln -s /dev/null /etc/tmpfiles.d/linux-firmware.conf<br />
<br />
== Verifying that microcode got updated on boot ==<br />
<br />
{{Expansion|The kernel ring buffer has a limited size, so, if the system was booted some while ago, the microcode messages might already be gone. Use {{ic|1=journalctl -k --grep='microcode'}} instead.}}<br />
<br />
Use ''dmesg'' to see if the microcode has been updated:<br />
<br />
$ dmesg | grep microcode<br />
<br />
On Intel systems one should see something similar to the following on every boot, indicating that microcode is updated very early on:<br />
<br />
[ 0.000000] CPU0 microcode updated early to revision 0x1b, date = 2014-05-29<br />
[ 0.221951] CPU1 microcode updated early to revision 0x1b, date = 2014-05-29<br />
[ 0.242064] CPU2 microcode updated early to revision 0x1b, date = 2014-05-29<br />
[ 0.262349] CPU3 microcode updated early to revision 0x1b, date = 2014-05-29<br />
[ 0.507267] microcode: CPU0 sig=0x306a9, pf=0x2, revision=0x1b<br />
[ 0.507272] microcode: CPU1 sig=0x306a9, pf=0x2, revision=0x1b<br />
[ 0.507276] microcode: CPU2 sig=0x306a9, pf=0x2, revision=0x1b<br />
[ 0.507281] microcode: CPU3 sig=0x306a9, pf=0x2, revision=0x1b<br />
[ 0.507286] microcode: CPU4 sig=0x306a9, pf=0x2, revision=0x1b<br />
[ 0.507292] microcode: CPU5 sig=0x306a9, pf=0x2, revision=0x1b<br />
[ 0.507296] microcode: CPU6 sig=0x306a9, pf=0x2, revision=0x1b<br />
[ 0.507300] microcode: CPU7 sig=0x306a9, pf=0x2, revision=0x1b<br />
[ 0.507335] microcode: Microcode Update Driver: v2.2.<br />
<br />
{{Note|The date displayed does not correspond to the version of the {{Pkg|intel-ucode}} package installed. It does show the last time Intel updated the microcode that corresponds to the specific hardware being updated.}}<br />
<br />
It is entirely possible, particularly with newer hardware, that there is no microcode update for the CPU. In that case, the output may look like this:<br />
<br />
[ 0.292893] microcode: CPU0 sig=0x306c3, pf=0x2, revision=0x1c<br />
[ 0.292899] microcode: CPU1 sig=0x306c3, pf=0x2, revision=0x1c<br />
[ 0.292906] microcode: CPU2 sig=0x306c3, pf=0x2, revision=0x1c<br />
[ 0.292912] microcode: CPU3 sig=0x306c3, pf=0x2, revision=0x1c<br />
[ 0.292956] microcode: Microcode Update Driver: v2.2.<br />
<br />
On AMD systems using early loading the output would look something like this:<br />
<br />
[ 2.119089] microcode: microcode updated early to new patch_level=0x0700010f<br />
[ 2.119157] microcode: CPU0: patch_level=0x0700010f<br />
[ 2.119171] microcode: CPU1: patch_level=0x0700010f<br />
[ 2.119183] microcode: CPU2: patch_level=0x0700010f<br />
[ 2.119189] microcode: CPU3: patch_level=0x0700010f<br />
[ 2.119269] microcode: Microcode Update Driver: v2.2.<br />
<br />
On AMD systems using late loading the output will show the version of the old microcode before reloading the microcode and the new one once it is reloaded. It would look something like this:<br />
<br />
[ 2.112919] microcode: CPU0: patch_level=0x0700010b<br />
[ 2.112931] microcode: CPU1: patch_level=0x0700010b<br />
[ 2.112940] microcode: CPU2: patch_level=0x0700010b<br />
[ 2.112951] microcode: CPU3: patch_level=0x0700010b<br />
[ 2.113043] microcode: Microcode Update Driver: v2.2.<br />
[ 6.429109] microcode: CPU2: new patch_level=0x0700010f<br />
[ 6.430416] microcode: CPU0: new patch_level=0x0700010f<br />
[ 6.431722] microcode: CPU1: new patch_level=0x0700010f<br />
[ 6.433029] microcode: CPU3: new patch_level=0x0700010f<br />
[ 6.433073] x86/CPU: CPU features have changed after loading microcode, but might not take effect.<br />
<br />
== Which CPUs accept microcode updates ==<br />
<br />
Users may consult either Intel or AMD at the following links to see if a particular model is supported:<br />
<br />
* [http://www.amd64.org/microcode.html AMD's Operating System Research Center]{{Dead link|2019|07|01}}.<br />
* [https://downloadcenter.intel.com/SearchResult.aspx?lang=eng&keyword=processor%20microcode%20data%20file Intel's download center].<br />
<br />
=== Detecting available microcode update ===<br />
<br />
It is possible to find out if the {{ic|intel-ucode.img}} contains a microcode image for the running CPU with {{Pkg|iucode-tool}}.<br />
<br />
# [[Install]] {{Pkg|intel-ucode}} (changing initrd is not required for detection)<br />
# [[Install]] {{Pkg|iucode-tool}}<br />
# {{bc|# modprobe cpuid}}<br />
# Extract microcode image and search it for your cpuid:<br/>{{bc|# bsdtar -Oxf /boot/intel-ucode.img {{!}} iucode_tool -tb -lS -}}<br />
# If an update is available, it should show up below ''selected microcodes''<br />
# The microcode might already be in your vendor bios and not show up loading in dmesg. Compare to the current microcode running {{ic|grep microcode /proc/cpuinfo}}<br />
<br />
== See also ==<br />
<br />
* [https://flossexperiences.wordpress.com/2013/11/17/updating-microcodes/ Updating microcodes – Experiences in the community]<br />
* [http://inertiawar.com/microcode/ Notes on Intel Microcode updates – Ben Hawkes]<br />
* [https://www.kernel.org/doc/Documentation/x86/microcode.txt Kernel microcode loader – kernel documentation]<br />
* [http://www.anandtech.com/show/8376/intel-disables-tsx-instructions-erratum-found-in-haswell-haswelleep-broadwelly Erratum found in Haswell/Broadwell – AnandTech]<br />
* [https://gitlab.com/iucode-tool/iucode-tool iucode-tool GitLab project]</div>Hardfalconhttps://wiki.archlinux.org/index.php?title=DeveloperWiki:Pacman_Hooks&diff=432293DeveloperWiki:Pacman Hooks2016-04-23T07:53:00Z<p>Hardfalcon: /* OTHER */</p>
<hr />
<div>=Hooks!=<br />
<br />
==update-desktop-database==<br />
Used by 490 packages<br />
<br />
Proposed Hook (desktop-file-utils)<br />
[Trigger]<br />
Type = File<br />
Operation = Install<br />
Operation = Upgrade<br />
Operation = Remove<br />
Target = usr/share/applications/*.desktop<br />
<br />
[Action]<br />
Description = Updating desktop file MIME types cache database...<br />
When = PostTransaction<br />
Exec = /usr/bin/update-desktop-database --quiet<br />
<br />
==update-mime-database==<br />
Used by 142 packages<br />
<br />
Proposed Hook (shared-mime-info)<br />
[Trigger]<br />
Type = File<br />
Operation = Install<br />
Operation = Upgrade<br />
Operation = Remove<br />
Target = usr/share/mime/packages/*.xml<br />
<br />
[Action]<br />
Description = Updating the Shared MIME-Info database cache...<br />
When = PostTransaction<br />
Exec = /usr/bin/update-mime-database /usr/share/mime<br />
<br />
==install-info==<br />
Used by 170 packages<br />
<br />
Proposed Hook (install/upgrade)<br />
[Trigger]<br />
Type = File<br />
Operation = Install<br />
Operation = Upgrade<br />
Target = usr/share/info/*<br />
<br />
[Action]<br />
Description = Updating the info directory file...<br />
When = PostTransaction<br />
Exec = /bin/sh -c 'while read -r f; do install-info "$f" /usr/share/info/dir 2> /dev/null; done'<br />
NeedsTargets<br />
<br />
Proposed Hook (remove)<br />
[Trigger]<br />
Type = File<br />
Operation = Remove<br />
Target = usr/share/info/*<br />
<br />
[Action]<br />
Description = Remove old entries from the info directory file...<br />
When = PostTransaction<br />
Exec = /bin/sh -c 'while read -r f; do install-info --delete "$f" /usr/share/info/dir 2> /dev/null; done'<br />
NeedsTargets<br />
<br />
==OTHER==<br />
* mkfontdir<br />
* fc-cache<br />
* gtk-update-icon-cache<br />
* xdg-icon-resource<br />
* secureboot-linux, secureboot-linux-lts, secureboot-linux-grsec, etc (use sbsigntools to sign /boot/vmlinuz-* with user's custom secureboot key after kernel updates)</div>Hardfalconhttps://wiki.archlinux.org/index.php?title=DeveloperWiki:Pacman_Hooks&diff=432292DeveloperWiki:Pacman Hooks2016-04-23T07:52:36Z<p>Hardfalcon: /* OTHER */ secureboot-linux</p>
<hr />
<div>=Hooks!=<br />
<br />
==update-desktop-database==<br />
Used by 490 packages<br />
<br />
Proposed Hook (desktop-file-utils)<br />
[Trigger]<br />
Type = File<br />
Operation = Install<br />
Operation = Upgrade<br />
Operation = Remove<br />
Target = usr/share/applications/*.desktop<br />
<br />
[Action]<br />
Description = Updating desktop file MIME types cache database...<br />
When = PostTransaction<br />
Exec = /usr/bin/update-desktop-database --quiet<br />
<br />
==update-mime-database==<br />
Used by 142 packages<br />
<br />
Proposed Hook (shared-mime-info)<br />
[Trigger]<br />
Type = File<br />
Operation = Install<br />
Operation = Upgrade<br />
Operation = Remove<br />
Target = usr/share/mime/packages/*.xml<br />
<br />
[Action]<br />
Description = Updating the Shared MIME-Info database cache...<br />
When = PostTransaction<br />
Exec = /usr/bin/update-mime-database /usr/share/mime<br />
<br />
==install-info==<br />
Used by 170 packages<br />
<br />
Proposed Hook (install/upgrade)<br />
[Trigger]<br />
Type = File<br />
Operation = Install<br />
Operation = Upgrade<br />
Target = usr/share/info/*<br />
<br />
[Action]<br />
Description = Updating the info directory file...<br />
When = PostTransaction<br />
Exec = /bin/sh -c 'while read -r f; do install-info "$f" /usr/share/info/dir 2> /dev/null; done'<br />
NeedsTargets<br />
<br />
Proposed Hook (remove)<br />
[Trigger]<br />
Type = File<br />
Operation = Remove<br />
Target = usr/share/info/*<br />
<br />
[Action]<br />
Description = Remove old entries from the info directory file...<br />
When = PostTransaction<br />
Exec = /bin/sh -c 'while read -r f; do install-info --delete "$f" /usr/share/info/dir 2> /dev/null; done'<br />
NeedsTargets<br />
<br />
==OTHER==<br />
* mkfontdir<br />
* fc-cache<br />
* gtk-update-icon-cache<br />
* xdg-icon-resource<br />
* secureboot-linux, secureboot-linux-lts, secureboot-linux-grsec, etc (use sbsigntools to sign /boot/vmlinuz-* with user's custom secure boot key after kernel updates)</div>Hardfalconhttps://wiki.archlinux.org/index.php?title=Talk:VCS_package_guidelines&diff=271473Talk:VCS package guidelines2013-08-17T21:22:32Z<p>Hardfalcon: /* git pkgver: Date of last commit at the beginning of the version number for compatibility with older PKGBUILDs from AUR? */ new section</p>
<hr />
<div>== https:// vs git:// ==<br />
<br />
Could we consider a guideline to use firewall-friendly protocols when possible (e.g. https://github.com/matplotlib/matplotlib.git instead of git://github.com/matplotlib/matplotlib.git)?<br />
--[[User:Mitch feaster|Mitch feaster]] 14:34, 15 November 2011 (EST)<br />
<br />
:It shouldn't be too hard to just mention that. As I haven't heard of anybody else ever bringing it up, it'd probably be enough.<br />
:--[[User:Det|Det]] ([[User talk:Det|talk]]) 22:51, 2 May 2013 (UTC)<br />
<br />
== Updating a CVS repo ==<br />
I don't use cvs. How can you describe the pkgver for cvs (for pacman 4.1)? <br><br />
-- [[User:Dracorp|Dracorp]] ([[User talk:Dracorp|talk]]) 09:31, 6 April 2013 (UTC)<br />
<br />
:CVS is not supported in pacman 4.1 like the other VCS tools. You will need to update pkgver manually until CVS support is added.<br />
:-- [[User:Jstjohn|Jstjohn]] ([[User talk:Jstjohn|talk]]) 22:44, 15 April 2013 (UTC)<br />
<br />
::Yeah, but how about mentioning that in the article (as well as giving a download example)? Even if it's not that common anymore.<br />
::--[[User:Det|Det]] ([[User talk:Det|talk]]) 22:39, 2 May 2013 (UTC)<br />
<br />
:::The download example can still be found in {{ic|/usr/share/pacman/}}. The next version of the ABS package should update it a bit so the download happens in the prepare function where it belongs. As for pkgver, I think the generic example using date covers that, as there's not a way to get a version number from a CVS repo. Maybe a note to that effect?<br />
::: -- [[User:Scimmia|Scimmia]] ([[User talk:Scimmia|talk]]) 07:17, 15 May 2013 (UTC)<br />
<br />
::::That makes the most sense, but it might also be a good idea to rename the [[VCS PKGBUILD Guidelines#Fallback|"Fallback"]] section to something like "Fallback / CVS" to make it more obvious even when you're just checking out the table of contents.<br />
<br />
::::But as for ABS, as far as I can tell the last commit was over [https://projects.archlinux.org/abs.git/log/ 8 months] ago.<br />
::::--[[User:Det|Det]] ([[User talk:Det|talk]]) 05:54, 19 May 2013 (UTC)<br />
<br />
:::::Hmm, there were a number of patches submitted last month for cleaning up the prototypes, looks like none have been committed yet. I do remember a discussion (IRC maybe?) questioning the proper place for the prototypes, so maybe that's why? Looking at the patches, I was mistaken anyway; they didn't update the darcs or cvs prototypes. Simple enough, I'll send in a patch myself.<br />
:::::--[[User:Scimmia|Scimmia]] ([[User talk:Scimmia|talk]]) 08:22, 19 May 2013 (UTC)<br />
<br />
: I use this dirty hack: {{ic|<nowiki>cvs history -c -a | cut -d' ' -f2 | sort -u | tail -n 1 | sed 's|-||g"</nowiki>}} ; could probably be improved. --[[User:Buhman|Buhman]] ([[User talk:Buhman|talk]]) 18:00, 6 June 2013 (UTC)<br />
<br />
== Checking out branches/tags needs clarification ==<br />
<br />
The {{ic|#fragment}} part of the VCS source URL has a different meaning for each type of VCS.<br />
This can be confusing for people, especially when they are trying to checkout a specific branch or tag.<br />
Examples would reduce the chance for confusion a lot.<br />
<br />
fictional examples for git and svn (don't have experience with bzr or HG)<br />
<br />
check out branch {{ic|git_test}} of git://myproject.com into folder {{ic|my_git_code}} :<br />
my_git_code::git://myproject.com/'''#branch=git_test'''<br />
<br />
Check out branch {{ic|svn_test}} of svn://myproject.com into folder {{ic|my_svn_code}} :<br />
my_svn_code::svn://myproject.com/'''branches/svn_test'''<br />
<br />
[[User:Lone Wolf|Lone_Wolf]] ([[User talk:Lone Wolf|talk]]) 20:49, 16 April 2013 (UTC)<br />
<br />
:Makes sense. At least for those two.<br />
:--[[User:Det|Det]] ([[User talk:Det|talk]]) 22:53, 2 May 2013 (UTC)<br />
<br />
== More on git pkgver()'s ==<br />
<br />
I would also like to see packages use {{ic|pkgver}} functions like this:<br />
<br />
git describe --always --long | sed -E 's/([^-]*-g)/r\1/;s/-/./g'<br />
<br />
so they are more friendly to {{ic|vercmp}}. <br />
Current behaviour using git-git as an example:<br />
<br />
current ver: {{ic|1.8.2.210.g123abc-1}}<br />
next ver: {{ic|1.8.2.1.50.g123abc-1}}<br />
vercmp 1.8.2.210.g123abc 1.8.2.1.50.g123abc<br />
1 # the first is greater than the second<br />
<br />
Right now, the current version is actually greater than the new version, causing a downgrade. If {{ic|r}} is appended to the patch level (the numbers just before the {{ic|g<hex>}} bit), then {{ic|vercmp}} would order the versions correctly.<br />
<br />
current ver: {{ic|1.8.2.r210.g123abc-1}}<br />
next ver: {{ic|1.8.2.1.r50.g123abc-1}}<br />
vercmp 1.8.2.r210.g123abc 1.8.2.1.r50.g123abc<br />
-1 # the first is less than the second<br />
<br />
[[User:KaiSforza|KaiSforza]] ([[User talk:KaiSforza|talk]]) 20:42, 18 April 2013 (UTC)<br />
<br />
:So Git makes some projects jump down from {{ic|x.x.x.210}} to {{ic|x.x.x.x.50}}? Is that really intended behavior?<br />
:--[[User:Det|Det]] ([[User talk:Det|talk]]) 22:48, 2 May 2013 (UTC)<br />
<br />
::Yes, that's intended behavior. That number is the number of commits since the last tag, so it will reset every time the author tags a new commit.<br />
::[[User:Scimmia|Scimmia]] ([[User talk:Scimmia|talk]]) 08:02, 4 May 2013 (UTC)<br />
<br />
:::I noticed just now there's the {{ic|.1}}.<br />
:::--[[User:Det|Det]] ([[User talk:Det|talk]]) 20:44, 14 May 2013 (UTC)<br />
<br />
::::Why not make the change for use {{ic|.r}} or {{ic|~}} instead from the actual {{ic|.}} for prevent that problem<br />
::::--[[User:Jristz|Jristz]] ([[User talk:Jristz|talk]]) 18:52, 17 May 2013 (UTC)<br />
<br />
:::::Well, that's what's being suggested..<br />
:::::--[[User:Det|Det]] ([[User talk:Det|talk]]) 05:57, 19 May 2013 (UTC)<br />
<br />
:I have the same issue with tup--git package that bumped its version from {{ic|0.6}} to {{ic|0.6.5}}. previously generated version was {{ic|0.6.350.gfoobar}} now it became {{ic|0.6.5}} that is smaller than previous. Generated version should split upstream version from 'git describe' version. My vote is goes to '~' delimiter proposed above. Or maybe we can use '-' as delimiter?<br />
:--[[User:Anatolik|Anatolik]] ([[User talk:Anatolik|talk]]) 11:43, 17 Jun 2013 (UTC)<br />
::You can't have a '-' in the pkgver, so that's out. '~' is an option, but I kind of like the suggested '.r'. Seems cleaner to me.<br />
::[[User:Scimmia|Scimmia]] ([[User talk:Scimmia|talk]]) 16:47, 26 July 2013 (UTC)<br />
<br />
== Clarifying the first Git function ==<br />
Instead of just {{ic|<nowiki>sed 's|-|.|g'</nowiki>}} it'd probably be better to give some example with {{ic|cut}} (which you're probably gonna end up using anyway) and {{ic|tr}} (which is simpler than {{ic|sed}}). Then you could either explain it like this or just mention the man pages: ''"{{ic|cut -d "-" -f2-}} cuts from the first hyphen (-) to the end, {{ic|tr - .}} converts hyphens to dots (.) and {{ic|tr -d -}} removes the hyphens"''.<br />
<br />
Example:<br />
{{hc|<nowiki>pkgver() {<br />
cd local_repo<br />
git describe --always | cut -d "-" -f2- | tr - .<br />
}</nowiki>|<br />
2.0.6.a17a017<br />
}}<br />
{{Note|See the man pages of [http://unixhelp.ed.ac.uk/CGI/man-cgi?cut cut(1)] and [http://unixhelp.ed.ac.uk/CGI/man-cgi?tr+1 tr(1)] for more info.}}<br />
--[[User:Det|Det]] ([[User talk:Det|talk]]) 00:22, 3 May 2013 (UTC)<br />
<br />
:Did you test this before posting? It doesn't do anything like you think it does. [[User:Scimmia|Scimmia]] ([[User talk:Scimmia|talk]]) 22:29, 4 May 2013 (UTC)<br />
<br />
::Well, my friend, that's what makes it an ''example''. The reason I'm using {{ic|cut}} is to remove the actual project names that are often included in their tags. All the sed example does is change the hyphens ({{ic|-}}) to dots ({{ic|.}}), which is simpler to do with {{ic|tr - .}} anyway.<br />
<br />
::What _makes_ it so hard is that there ''isn't'' a single solution that somehow magicly worked on all scenarios. Even if you decided to be clever and started cutting the output up until the first number (with something like {{ic|$ sed 's/\([^0-9]*\)\(.*\)/\2/g'}}), you'd still end up with the wrong result whenever the "version" starts with a letter or the project name ends with a number.<br />
::--[[User:Det|Det]] ([[User talk:Det|talk]]) 21:04, 7 May 2013 (UTC)<br />
<br />
:::Ah, I see now, you were addressing a special case. You're right, there ''isn't'' a single solution. You're also right that {{ic|tr}} is simpler and should probably be used in the example if that's all the example is going to show. It seems to be fairly common, though, to include a "v" at the beginning of the version number, in which case you'd already be using {{ic|sed}} anyway so you can just do {{ic|sed 's/^v//;s/-/./g'}} So many ways of doing the same job. [[User:Scimmia|Scimmia]] ([[User talk:Scimmia|talk]]) 02:15, 8 May 2013 (UTC)<br />
<br />
::::That only works when they do. It doesn't remove the names from the tags, which are included in things like Wine and the entire X stack.<br />
::::{{ic|<nowiki>git describe --always | sed 's/\([^0-9]*\)\(.*\)/\2/g; s/-/./g'</nowiki>}} is the most universal approach I can think of. But it's totally unreadable and a damn lot harder to edit than some {{ic|cut}}/{{ic|tr}} example.<br />
:::: --[[User:Det|Det]] ([[User talk:Det|talk]]) 20:37, 14 May 2013 (UTC)<br />
<br />
:::::Yeah, my example was a special case as well. I'm really thinking that this is a situation where it's best just to include a very simple example and let the maintainer customize it as needed instead of trying to find a convoluted solution that works everywhere.<br />
::::: -- [[User:Scimmia|Scimmia]] ([[User talk:Scimmia|talk]]) 07:11, 15 May 2013 (UTC)<br />
<br />
::::::In that sense the current one is pretty fitting, but it sort of gives the impression that it works "right away", which it doesn't. So at least a note for probably having to do something yourself would be good.<br />
::::::--[[User:Det|Det]] ([[User talk:Det|talk]]) 06:03, 19 May 2013 (UTC)<br />
<br />
== Use --long insead of --always in git describe ==<br />
<br />
--always is for returning something even when it can't find a tag. It just returns the short hash of the commit, which is kind of useless in this example.<br />
On the other hand --long is needed to get the output we want if HEAD has a tag. By default, git describe would just return the name of the tag, --long forces it to return the full output we want, ie "2.0-0-g123abcd" instead of just "2.0".<br />
--[[User:Scimmia|Scimmia]] ([[User talk:Scimmia|talk]]) 09:40, 22 May 2013 (UTC)<br />
<br />
== pkgver function for hg based on tags ==<br />
<br />
I recent came across a way with hg to show the most recent tag, as well as the number of commits from this tag (similar to the output of `git describe`.) <br />
<br />
{{hc|<nowiki>pkgver() {<br />
cd local_repo<br />
hg log -r . --template '{latesttag}.{latesttagdistance}.{node|short}\n'<br />
}</nowiki>|<br />
3.0.1.40.ee9a2543fcd6<br />
}}<br />
<br />
Please could this be included in the page.<br />
<br />
[[User:Garyvdm|Garyvdm]] ([[User talk:Garyvdm|talk]]) 09:03, 23 July 2013 (UTC)<br />
<br />
== Support for shallow copies ==<br />
<br />
Some git repositories are really really large, and forcing a full copy on the initial download might not be ideal. Git (don't know about the other VCSs) supports passing a --depth option to only download the last couple of commits rather than everything. Thoughts on including this functionality somehow in the PKGBUILD VCS support?<br />
<br />
[[User:Jonhoo|Jonhoo]] ([[User talk:Jonhoo|talk]]) 18:14, 26 July 2013 (UTC)<br />
<br />
:Does this work with a bare clone? Check the pacman-devel mailing list, I seem to remember this being discussed and rejected. This talk page really isn't the place to discuss changes to pacman, anyway.<br />
:also, please sign your posts with 4 tildes<br />
:[[User:Scimmia|Scimmia]] ([[User talk:Scimmia|talk]]) 15:17, 26 July 2013 (UTC)<br />
<br />
::Shallow cloning should work fine from a bare clone.<br />
::After a bit of Googling, I came up with [https://mailman.archlinux.org/pipermail/aur-general/2013-April/022938.html (aur-general) please add -depth 1 to makepkg git clone] and [https://mailman.archlinux.org/pipermail/pacman-dev/2013-February/016468.html (pacman-dev) (PATCH) Use shallow clones for git sources to reduce traffic], so should anyone else want to discuss it, that's probably a better place to continue the discussion as [[User:Scimmia|Scimmia]] pointed out.<br />
::(Oh, and I added the signature to my original post too)<br />
::[[User:Jonhoo|Jonhoo]] ([[User talk:Jonhoo|talk]]) 18:14, 26 July 2013 (UTC)<br />
<br />
== git pkgver: Date of last commit at the beginning of the version number for compatibility with older PKGBUILDs from AUR? ==<br />
<br />
We have quite a bunch of older PKGBUILDs for -git packages in AUR which still work but which do not have a pkgver function yet. Many of these actually carry a date as version number (mostly the date of the last git commit at the time when the PKGBUILD was last updated).<br />
<br />
When you update these scripts to use one of the two pkgver functions suggested on the wiki page, AUR helpers like packer will (in most cases) suggest that there is a newer version in AUR on every system update. My proposal to solve this problem is a pkgver function which precedes the generated version number with the date of the last git commit:<br />
<br />
{{bc|<nowiki><br />
pkgver() {<br />
cd "${_pkgname}"<br />
echo $(git log -n 1 --date=short | sed -nr 's|^Date:\s+([0-9]{4})-([0-9]{2})-([0-9]{2})$|\1\2\3|p').$(git rev-list --count HEAD).$(git rev-parse --short HEAD)<br />
}<br />
</nowiki>}}<br />
<br />
This function is *not* intended to go into PKGBUILDs in AUR, but could be proposed as a temporary "local" fix in the wiki for the period of time until the package maintainer has found time to update his PKGBUILD in AUR.<br />
<br />
--[[User:Hardfalcon|Hardfalcon]] ([[User talk:Hardfalcon|talk]]) 21:22, 17 August 2013 (UTC)</div>Hardfalconhttps://wiki.archlinux.org/index.php?title=Netctl&diff=253627Netctl2013-04-10T16:26:14Z<p>Hardfalcon: /* Installation */ ifenslaved -> ifenslave</p>
<hr />
<div>{{Lowercase title}}<br />
[[Category:Networking]]<br />
[[es:Netcfg]]<br />
[[fr:Netctl]]<br />
[[it:Netcfg]]<br />
[[ja:Netcfg]]<br />
[[ro:Netcfg]]<br />
[[ru:Netcfg]]<br />
[[tr:netcfg]]<br />
[[zh-CN:Netcfg]]<br />
{{Article summary start}}<br />
{{Article summary text|A guide to configuring the network using netctl and network profile scripts.}}<br />
{{Article summary end}}<br />
Netctl is a new Arch project slated to replace [[netcfg]]. Users should regard it as the future of CLI-based network management on Arch Linux.<br />
<br />
==Installation==<br />
The {{Pkg|netctl}} package is available in [[Official Repositories#&#91;core&#93;|&#91;core&#93;]]. Installing netctl will replace netcfg. As of netctl version 0.7, optional dependencies include<br />
*{{Pkg|dialog}}, for menu based WiFi assistance ({{ic|wifi-menu}})<br />
*{{Pkg|dhclient}}, for DHCP support<br />
*{{Pkg|dhcpcd}}, for DHCP support (instead of dhclient)<br />
*{{Pkg|wpa_supplicant}}, for wireless network support<br />
*{{Pkg|ifplugd}}, for automatic wired connections through {{ic|netctl-ifplugd}}<br />
*{{Pkg|ifenslave}}, for bond connections<br />
*{{Pkg|bridge-utils}}, for bridge connections<br />
*{{Pkg|ppp}}, for pppoe connection<br />
<br />
==Recommended Reading==<br />
Considerable effort has gone into the construction of quality man pages. Users are encouraged to read the following man pages prior to using netctl:<br />
*netctl<br />
*netctl.profile<br />
*netctl.special<br />
<br />
==Configuration==<br />
<br />
{{ic|netctl}} may be used to introspect and control the state of the systemd services for the network profile manager. Example configuration files are provided for the user to assist them in configuring their network connection. These example profiles are located in {{ic|/etc/netctl/examples/}}. The common configurations include:<br />
*ethernet-dhcp<br />
*ethernet-static<br />
*wireless-wpa<br />
*wireless-wpa-static<br />
<br />
To use an example profile, simply copy one of them from {{ic|/etc/netctl/examples/<profile>}} to {{ic|/etc/netctl/<profile>}} and configure it to your needs:<br />
# cp /etc/netctl/examples/wireless-wpa /etc/netctl/my-wireless-wpa<br />
<br />
Once you have created your profile, make an attempt to establish a connection using the newly created profile by running:<br />
# netctl start <profile><br />
<br />
If issuing the above command results in a failure, then use {{ic|journalctl -xn}} and {{ic|netctl status <profile>}} in order to obtain a more in depth explanation of the failure. Make the needed corrections to the failed configuration and retest.<br />
<br />
Once the profile is started successfully then it can be {{ic|enabled}} using {{ic|netctl enable <profile>}}. This will create the proper symlink for the profile to be used by {{ic|netctl-auto@.service}}.<br />
<br />
{{Note| the systemd service {{ic|netctl-auto@<interface>.service}} will need to be enabled in order to allow automatic wireless connection at boot to become functional.}}<br />
<br />
{{Note| If there is ever a need to alter a currently enabled profile. execute {{ic|netctl reenable <profile>}} to apply the changes.}}<br />
<br />
===Migrating from netcfg===<br />
<br />
{{ic|netctl}} uses {{ic|/etc/netctl}} to store its profiles, ''not'' {{ic|/etc/network.d}} ({{ic|netcfg}}'s profile storage location).<br />
<br />
In order to migrate from netcfg, at least the following is needed:<br />
*Move network profile files to the new directory.<br />
*Rename variables therein according to netctl.profile(5) (most have only become CamelCase i.e CONNECTION= becomes Connection=).<br />
*Unquote interface variables and other variables that don't strictly need quoting (this is mainly a style thing).<br />
*Run {{ic|netctl enable <profile>}} for every profile in the old NETWORKS array. 'last' doesn't work this way, see netctl.special(7).<br />
*Use {{ic|netctl list}} / {{ic|netctl start <profile>}} instead of netcfg-menu. wifi-menu remains available.<br />
<br />
===Password Encryption (256-bit PSK)===<br />
<br />
Users ''not'' wishing to have their passwords stored in ''plain text'' have the option of generating a 256-bit Encrypted PSK.<br />
<br />
If you have not done so already, install {{pkg|wpa_actiond}} from the [[Official Repositories#&#91;core&#93;|&#91;core&#93;]] repository using [[pacman]]<br />
# pacman -S wpa_actiond<br />
<br />
Next, generate your 256-bit Encrypted PSK using [[WPA_supplicant#Configuration_file|wpa_passphrase]]:<br />
{{hc|Usage: wpa_passphrase [ssid] [passphrase]|<br />
2=$ wpa_passphrase archlinux freenode|<br />
network={<br />
ssid="archlinux"<br />
#psk="freenode"<br />
psk=64cf3ced850ecef39197bb7b7b301fc39437a6aa6c6a599d0534b16af578e04a<br />
}<br />
{{Note|This information will be used in your profile so do not close the terminal}}<br />
}}<br />
<br />
In a second terminal window copy the example file {{ic|wireless-wpa}} from {{ic|/etc/netctl/examples}} to {{ic|/etc/netctl}}.<br />
# cp /etc/netctl/examples/wireless-wpa /etc/netctl/wireless-wpa<br />
<br />
You will then need to edit {{ic|/etc/netctl/wireless-wpa}} using your favorite text editor and add the ''Encrypted Pre-shared Key'' that was generated early using wpa_passphrase to the {{ic|'''Key'''}} variable of this profile.<br />
<br />
Once completed your network profile {{ic|wireless-wpa}} containing a 256-bit Encrypted PSK should resemble:<br />
{{hc|/etc/netctl/wireless-wpa|2=<br />
Description='A simple WPA encrypted wireless connection using 256-bit Encrypted PSK'<br />
Interface=wlp2s2<br />
Connection=wireless<br />
Security=wpa<br />
IP=dhcp<br />
ESSID=archlinux<br />
Key=\"64cf3ced850ecef39197bb7b7b301fc39437a6aa6c6a599d0534b16af578e04a<br />
}}<br />
{{Note|1=Make sure to use the '''special non-quoted rules''' for Key= that are explained at the end of [https://github.com/joukewitteveen/netctl/blob/master/docs/netctl.profile.5.txt netctl.profile(5)]}}<br />
<br />
<br />
==Support==<br />
Official announcement thread: https://bbs.archlinux.org/viewtopic.php?id=157670</div>Hardfalconhttps://wiki.archlinux.org/index.php?title=Touchatag_RFID_Reader&diff=142437Touchatag RFID Reader2011-05-22T12:37:17Z<p>Hardfalcon: /* Other related packages */ Added libnfc</p>
<hr />
<div>[[Category:Other hardware (English)]]<br />
[[Category:HOWTOs (English)]]<br />
Touchatag is a RFID Reader<br />
<br />
== About Touchatag ==<br />
<br />
Touchatag is a RFID tag reader from [http://www.touchatag.com/ Touchatag]. It is a cheap set consisting of an ACR122U USB tag reader and MiFare Ultralight RFID tags.<br />
<br />
It is available [http://www.touchatag.com/e-store here] or for Europe [http://www.getdigital.de/products/Touchatag/lng/en here].<br />
<br />
'''Remember: Always put a tag on the reader, otherwise you might encounter problems!'''<br />
<br />
== Check hardware version ==<br />
<br />
lsusb shows the device:<br />
<br />
Bus 003 Device 004: ID 072f:2200 Advanced Card Systems, Ltd <br />
<br />
lsusb -v shows also the firmware version bcdDevice:<br />
<br />
idVendor 0x072f Advanced Card Systems, Ltd<br />
idProduct 0x2200 <br />
bcdDevice 1.00<br />
<br />
The Version this howto is about is the above ACS ACR122U PICC firmware 1.0.<br />
<br />
== Install Touchatag ==<br />
<br />
First install this:<br />
# pacman -S pcsclite pcsc-tools pcsc-perl ccid<br />
<br />
=== Install pcsclite-libudev ===<br />
<br />
The normal pcsclite package from the community repository uses libusb instead of udev, which causes problems when using the Touchatag reader. So we need to replace it with the [https://aur.archlinux.org/packages.php?ID=49245 pcsclite-libudev] package from AUR:<br />
# cd /tmp<br />
# wget https://aur.archlinux.org/packages/pcsclite-libudev/pcsclite-libudev.tar.gz<br />
# tar -xf pcsclite-libudev.tar.gz<br />
# cd pcsclite-libudev<br />
# makepkg<br />
# sudo pacman -U pcsclite-libudev-*.pkg.tar.xz<br />
<br />
=== Install the ACS CCID PC/SC driver ===<br />
<br />
Install the [https://aur.archlinux.org/packages.php?ID=49246 acsccid] package from AUR:<br />
# cd /tmp<br />
# wget https://aur.archlinux.org/packages/acsccid/acsccid.tar.gz<br />
# tar -xf acsccid.tar.gz<br />
# cd acsccid<br />
# makepkg<br />
# sudo pacman -U acsccid-*.pkg.tar.xz<br />
<br />
With old versions of the ACS driver, you can get errors like these:<br />
<br />
ifdhandler.c: In functie ‘IFDHControl’:<br />
ifdhandler.c:1304:8: fout: ‘PIN_PROPERTIES_STRUCTURE’ has no member named ‘wLcdMaxCharacters’<br />
ifdhandler.c:1305:8: fout: ‘PIN_PROPERTIES_STRUCTURE’ has no member named ‘wLcdMaxLines’<br />
<br />
In such a case, you can try commenting out those to lines in src/ifdhandler.c.<br />
<br />
== Test Touchatag ==<br />
<br />
Try to scan your Touchatag:<br />
<br />
# pcsc_scan<br />
<br />
You should get something like this:<br />
<br />
PC/SC device scanner<br />
V 1.4.17 (c) 2001-2009, Ludovic Rousseau <ludovic.rousseau@free.fr><br />
Compiled with PC/SC lite version: 1.6.6<br />
Scanning present readers...<br />
0: ACS ACR122U 00 00<br />
<br />
Mon Mar 21 18:16:07 2011<br />
Reader 0: ACS ACR122U 00 00<br />
Card state: Card inserted, Shared Mode, <br />
ATR: 3B BE 95 00 00 41 03 00 00 00 00 00 00 00 00 00 02 90 00 <br />
<br />
ATR: 3B BE 95 00 00 41 03 00 00 00 00 00 00 00 00 00 02 90 00<br />
+ TS = 3B --> Direct Convention<br />
+ T0 = BE, Y(1): 1011, K: 14 (historical bytes)<br />
TA(1) = 95 --> Fi=512, Di=16, 32 cycles/ETU<br />
125000 bits/s at 4 MHz, fMax for Fi = 5 MHz => 156250 bits/s <br />
TB(1) = 00 --> VPP is not electrically connected<br />
TD(1) = 00 --> Y(i+1) = 0000, Protocol T = 0 <br />
-----<br />
+ Historical bytes: 41 03 00 00 00 00 00 00 00 00 00 02 90 00<br />
Category indicator byte: 41 (proprietary format) <br />
<br />
Possibly identified card (using /usr/share/pcsc/smartcard_list.txt):<br />
3B BE 95 00 00 41 03 00 00 00 00 00 00 00 00 00 02 90 00<br />
touchatag SAM card<br />
<br />
If you encounter a problem like this:<br />
<br />
# pcscd -f<br />
<br />
ccid_usb.c:859:ccid_check_firmware() Firmware (1.00) is bogus! Upgrade the reader firmware or get a new reader.<br />
ifdhandler.c:104:IFDHCreateChannelByName() failed<br />
readerfactory.c:1050:RFInitializeReader() Open Port 200000 Failed (usb:072f/2200:libusb:006)<br />
readerfactory.c:233:RFAddReader() ACS ACR122U PICC Interface init failed.<br />
<br />
The [http://code.google.com/p/libnfc/source/browse/trunk/README libnfc README] suggests to do this:<br />
<br />
If your Touchatag or ACR122 device fails being detected by PCSC-lite daemon (pcsc_scan doesn't see anything) <br />
then try removing the bogus firmware detection of libccid: edit libccid_Info.plist configuration file <br />
(usually /etc/libccid_Info.plist) and locate "<key>ifdDriverOptions</key>", turn "<string>0x0000</string>" <br />
value into 0x0004 to allow bogus devices and restart pcscd daemon.<br />
<br />
Warning: if you use ACS CCID drivers (acsccid), configuration file is located in something like: <br />
/usr/lib/pcsc/drivers/ifd-acsccid.bundle/Contents/Info.plist<br />
<br />
== Install tagEventor ==<br />
<br />
[http://code.google.com/p/tageventor/ tagEventor] runs in the background and executes scripts when a tag enters or leaves your tag reader.<br />
<br />
Download a [http://code.google.com/p/tageventor/downloads/list binary version] or [http://code.google.com/p/tageventor/source/checkout compile] your own.<br />
<br />
Run tagEventor to test your installation:<br />
<br />
# tagEventor -v 1<br />
<br />
The scripts are located in /etc/gtagEventor. Read the [http://code.google.com/p/tageventor/ tagEventor documentation] on how to use them.<br />
<br />
== Other related packages ==<br />
<br />
The following AUR packages might also be worth a try:<br />
<br />
[https://aur.archlinux.org/packages.php?ID=33272 libnfc]<br />
<br />
[https://aur.archlinux.org/packages.php?ID=33274 mfoc]<br />
<br />
[https://aur.archlinux.org/packages.php?ID=49244 mfcuk-svn]</div>Hardfalconhttps://wiki.archlinux.org/index.php?title=Touchatag_RFID_Reader&diff=142436Touchatag RFID Reader2011-05-22T12:30:19Z<p>Hardfalcon: /* Other related packages */</p>
<hr />
<div>[[Category:Other hardware (English)]]<br />
[[Category:HOWTOs (English)]]<br />
Touchatag is a RFID Reader<br />
<br />
== About Touchatag ==<br />
<br />
Touchatag is a RFID tag reader from [http://www.touchatag.com/ Touchatag]. It is a cheap set consisting of an ACR122U USB tag reader and MiFare Ultralight RFID tags.<br />
<br />
It is available [http://www.touchatag.com/e-store here] or for Europe [http://www.getdigital.de/products/Touchatag/lng/en here].<br />
<br />
'''Remember: Always put a tag on the reader, otherwise you might encounter problems!'''<br />
<br />
== Check hardware version ==<br />
<br />
lsusb shows the device:<br />
<br />
Bus 003 Device 004: ID 072f:2200 Advanced Card Systems, Ltd <br />
<br />
lsusb -v shows also the firmware version bcdDevice:<br />
<br />
idVendor 0x072f Advanced Card Systems, Ltd<br />
idProduct 0x2200 <br />
bcdDevice 1.00<br />
<br />
The Version this howto is about is the above ACS ACR122U PICC firmware 1.0.<br />
<br />
== Install Touchatag ==<br />
<br />
First install this:<br />
# pacman -S pcsclite pcsc-tools pcsc-perl ccid<br />
<br />
=== Install pcsclite-libudev ===<br />
<br />
The normal pcsclite package from the community repository uses libusb instead of udev, which causes problems when using the Touchatag reader. So we need to replace it with the [https://aur.archlinux.org/packages.php?ID=49245 pcsclite-libudev] package from AUR:<br />
# cd /tmp<br />
# wget https://aur.archlinux.org/packages/pcsclite-libudev/pcsclite-libudev.tar.gz<br />
# tar -xf pcsclite-libudev.tar.gz<br />
# cd pcsclite-libudev<br />
# makepkg<br />
# sudo pacman -U pcsclite-libudev-*.pkg.tar.xz<br />
<br />
=== Install the ACS CCID PC/SC driver ===<br />
<br />
Install the [https://aur.archlinux.org/packages.php?ID=49246 acsccid] package from AUR:<br />
# cd /tmp<br />
# wget https://aur.archlinux.org/packages/acsccid/acsccid.tar.gz<br />
# tar -xf acsccid.tar.gz<br />
# cd acsccid<br />
# makepkg<br />
# sudo pacman -U acsccid-*.pkg.tar.xz<br />
<br />
With old versions of the ACS driver, you can get errors like these:<br />
<br />
ifdhandler.c: In functie ‘IFDHControl’:<br />
ifdhandler.c:1304:8: fout: ‘PIN_PROPERTIES_STRUCTURE’ has no member named ‘wLcdMaxCharacters’<br />
ifdhandler.c:1305:8: fout: ‘PIN_PROPERTIES_STRUCTURE’ has no member named ‘wLcdMaxLines’<br />
<br />
In such a case, you can try commenting out those to lines in src/ifdhandler.c.<br />
<br />
== Test Touchatag ==<br />
<br />
Try to scan your Touchatag:<br />
<br />
# pcsc_scan<br />
<br />
You should get something like this:<br />
<br />
PC/SC device scanner<br />
V 1.4.17 (c) 2001-2009, Ludovic Rousseau <ludovic.rousseau@free.fr><br />
Compiled with PC/SC lite version: 1.6.6<br />
Scanning present readers...<br />
0: ACS ACR122U 00 00<br />
<br />
Mon Mar 21 18:16:07 2011<br />
Reader 0: ACS ACR122U 00 00<br />
Card state: Card inserted, Shared Mode, <br />
ATR: 3B BE 95 00 00 41 03 00 00 00 00 00 00 00 00 00 02 90 00 <br />
<br />
ATR: 3B BE 95 00 00 41 03 00 00 00 00 00 00 00 00 00 02 90 00<br />
+ TS = 3B --> Direct Convention<br />
+ T0 = BE, Y(1): 1011, K: 14 (historical bytes)<br />
TA(1) = 95 --> Fi=512, Di=16, 32 cycles/ETU<br />
125000 bits/s at 4 MHz, fMax for Fi = 5 MHz => 156250 bits/s <br />
TB(1) = 00 --> VPP is not electrically connected<br />
TD(1) = 00 --> Y(i+1) = 0000, Protocol T = 0 <br />
-----<br />
+ Historical bytes: 41 03 00 00 00 00 00 00 00 00 00 02 90 00<br />
Category indicator byte: 41 (proprietary format) <br />
<br />
Possibly identified card (using /usr/share/pcsc/smartcard_list.txt):<br />
3B BE 95 00 00 41 03 00 00 00 00 00 00 00 00 00 02 90 00<br />
touchatag SAM card<br />
<br />
If you encounter a problem like this:<br />
<br />
# pcscd -f<br />
<br />
ccid_usb.c:859:ccid_check_firmware() Firmware (1.00) is bogus! Upgrade the reader firmware or get a new reader.<br />
ifdhandler.c:104:IFDHCreateChannelByName() failed<br />
readerfactory.c:1050:RFInitializeReader() Open Port 200000 Failed (usb:072f/2200:libusb:006)<br />
readerfactory.c:233:RFAddReader() ACS ACR122U PICC Interface init failed.<br />
<br />
The [http://code.google.com/p/libnfc/source/browse/trunk/README libnfc README] suggests to do this:<br />
<br />
If your Touchatag or ACR122 device fails being detected by PCSC-lite daemon (pcsc_scan doesn't see anything) <br />
then try removing the bogus firmware detection of libccid: edit libccid_Info.plist configuration file <br />
(usually /etc/libccid_Info.plist) and locate "<key>ifdDriverOptions</key>", turn "<string>0x0000</string>" <br />
value into 0x0004 to allow bogus devices and restart pcscd daemon.<br />
<br />
Warning: if you use ACS CCID drivers (acsccid), configuration file is located in something like: <br />
/usr/lib/pcsc/drivers/ifd-acsccid.bundle/Contents/Info.plist<br />
<br />
== Install tagEventor ==<br />
<br />
[http://code.google.com/p/tageventor/ tagEventor] runs in the background and executes scripts when a tag enters or leaves your tag reader.<br />
<br />
Download a [http://code.google.com/p/tageventor/downloads/list binary version] or [http://code.google.com/p/tageventor/source/checkout compile] your own.<br />
<br />
Run tagEventor to test your installation:<br />
<br />
# tagEventor -v 1<br />
<br />
The scripts are located in /etc/gtagEventor. Read the [http://code.google.com/p/tageventor/ tagEventor documentation] on how to use them.<br />
<br />
== Other related packages ==<br />
<br />
The following AUR packages might also be worth a try:<br />
<br />
[https://aur.archlinux.org/packages.php?ID=33274 mfoc]<br />
<br />
[https://aur.archlinux.org/packages.php?ID=49244 mfcuk-svn]</div>Hardfalconhttps://wiki.archlinux.org/index.php?title=Touchatag_RFID_Reader&diff=142435Touchatag RFID Reader2011-05-22T12:29:15Z<p>Hardfalcon: Added section "Other related packages"</p>
<hr />
<div>[[Category:Other hardware (English)]]<br />
[[Category:HOWTOs (English)]]<br />
Touchatag is a RFID Reader<br />
<br />
== About Touchatag ==<br />
<br />
Touchatag is a RFID tag reader from [http://www.touchatag.com/ Touchatag]. It is a cheap set consisting of an ACR122U USB tag reader and MiFare Ultralight RFID tags.<br />
<br />
It is available [http://www.touchatag.com/e-store here] or for Europe [http://www.getdigital.de/products/Touchatag/lng/en here].<br />
<br />
'''Remember: Always put a tag on the reader, otherwise you might encounter problems!'''<br />
<br />
== Check hardware version ==<br />
<br />
lsusb shows the device:<br />
<br />
Bus 003 Device 004: ID 072f:2200 Advanced Card Systems, Ltd <br />
<br />
lsusb -v shows also the firmware version bcdDevice:<br />
<br />
idVendor 0x072f Advanced Card Systems, Ltd<br />
idProduct 0x2200 <br />
bcdDevice 1.00<br />
<br />
The Version this howto is about is the above ACS ACR122U PICC firmware 1.0.<br />
<br />
== Install Touchatag ==<br />
<br />
First install this:<br />
# pacman -S pcsclite pcsc-tools pcsc-perl ccid<br />
<br />
=== Install pcsclite-libudev ===<br />
<br />
The normal pcsclite package from the community repository uses libusb instead of udev, which causes problems when using the Touchatag reader. So we need to replace it with the [https://aur.archlinux.org/packages.php?ID=49245 pcsclite-libudev] package from AUR:<br />
# cd /tmp<br />
# wget https://aur.archlinux.org/packages/pcsclite-libudev/pcsclite-libudev.tar.gz<br />
# tar -xf pcsclite-libudev.tar.gz<br />
# cd pcsclite-libudev<br />
# makepkg<br />
# sudo pacman -U pcsclite-libudev-*.pkg.tar.xz<br />
<br />
=== Install the ACS CCID PC/SC driver ===<br />
<br />
Install the [https://aur.archlinux.org/packages.php?ID=49246 acsccid] package from AUR:<br />
# cd /tmp<br />
# wget https://aur.archlinux.org/packages/acsccid/acsccid.tar.gz<br />
# tar -xf acsccid.tar.gz<br />
# cd acsccid<br />
# makepkg<br />
# sudo pacman -U acsccid-*.pkg.tar.xz<br />
<br />
With old versions of the ACS driver, you can get errors like these:<br />
<br />
ifdhandler.c: In functie ‘IFDHControl’:<br />
ifdhandler.c:1304:8: fout: ‘PIN_PROPERTIES_STRUCTURE’ has no member named ‘wLcdMaxCharacters’<br />
ifdhandler.c:1305:8: fout: ‘PIN_PROPERTIES_STRUCTURE’ has no member named ‘wLcdMaxLines’<br />
<br />
In such a case, you can try commenting out those to lines in src/ifdhandler.c.<br />
<br />
== Test Touchatag ==<br />
<br />
Try to scan your Touchatag:<br />
<br />
# pcsc_scan<br />
<br />
You should get something like this:<br />
<br />
PC/SC device scanner<br />
V 1.4.17 (c) 2001-2009, Ludovic Rousseau <ludovic.rousseau@free.fr><br />
Compiled with PC/SC lite version: 1.6.6<br />
Scanning present readers...<br />
0: ACS ACR122U 00 00<br />
<br />
Mon Mar 21 18:16:07 2011<br />
Reader 0: ACS ACR122U 00 00<br />
Card state: Card inserted, Shared Mode, <br />
ATR: 3B BE 95 00 00 41 03 00 00 00 00 00 00 00 00 00 02 90 00 <br />
<br />
ATR: 3B BE 95 00 00 41 03 00 00 00 00 00 00 00 00 00 02 90 00<br />
+ TS = 3B --> Direct Convention<br />
+ T0 = BE, Y(1): 1011, K: 14 (historical bytes)<br />
TA(1) = 95 --> Fi=512, Di=16, 32 cycles/ETU<br />
125000 bits/s at 4 MHz, fMax for Fi = 5 MHz => 156250 bits/s <br />
TB(1) = 00 --> VPP is not electrically connected<br />
TD(1) = 00 --> Y(i+1) = 0000, Protocol T = 0 <br />
-----<br />
+ Historical bytes: 41 03 00 00 00 00 00 00 00 00 00 02 90 00<br />
Category indicator byte: 41 (proprietary format) <br />
<br />
Possibly identified card (using /usr/share/pcsc/smartcard_list.txt):<br />
3B BE 95 00 00 41 03 00 00 00 00 00 00 00 00 00 02 90 00<br />
touchatag SAM card<br />
<br />
If you encounter a problem like this:<br />
<br />
# pcscd -f<br />
<br />
ccid_usb.c:859:ccid_check_firmware() Firmware (1.00) is bogus! Upgrade the reader firmware or get a new reader.<br />
ifdhandler.c:104:IFDHCreateChannelByName() failed<br />
readerfactory.c:1050:RFInitializeReader() Open Port 200000 Failed (usb:072f/2200:libusb:006)<br />
readerfactory.c:233:RFAddReader() ACS ACR122U PICC Interface init failed.<br />
<br />
The [http://code.google.com/p/libnfc/source/browse/trunk/README libnfc README] suggests to do this:<br />
<br />
If your Touchatag or ACR122 device fails being detected by PCSC-lite daemon (pcsc_scan doesn't see anything) <br />
then try removing the bogus firmware detection of libccid: edit libccid_Info.plist configuration file <br />
(usually /etc/libccid_Info.plist) and locate "<key>ifdDriverOptions</key>", turn "<string>0x0000</string>" <br />
value into 0x0004 to allow bogus devices and restart pcscd daemon.<br />
<br />
Warning: if you use ACS CCID drivers (acsccid), configuration file is located in something like: <br />
/usr/lib/pcsc/drivers/ifd-acsccid.bundle/Contents/Info.plist<br />
<br />
== Install tagEventor ==<br />
<br />
[http://code.google.com/p/tageventor/ tagEventor] runs in the background and executes scripts when a tag enters or leaves your tag reader.<br />
<br />
Download a [http://code.google.com/p/tageventor/downloads/list binary version] or [http://code.google.com/p/tageventor/source/checkout compile] your own.<br />
<br />
Run tagEventor to test your installation:<br />
<br />
# tagEventor -v 1<br />
<br />
The scripts are located in /etc/gtagEventor. Read the [http://code.google.com/p/tageventor/ tagEventor documentation] on how to use them.<br />
<br />
== Other related packages ==<br />
<br />
The following AUR packages might also be worth a try:<br />
[https://aur.archlinux.org/packages.php?ID=33274 mfoc]<br />
[https://aur.archlinux.org/packages.php?ID=49244 mfcuk-svn]</div>Hardfalconhttps://wiki.archlinux.org/index.php?title=Touchatag_RFID_Reader&diff=142434Touchatag RFID Reader2011-05-22T12:22:24Z<p>Hardfalcon: Deleted old or obsolete stuff and added references to the pcsclite-libudev and acsccid AUR packages</p>
<hr />
<div>[[Category:Other hardware (English)]]<br />
[[Category:HOWTOs (English)]]<br />
Touchatag is a RFID Reader<br />
<br />
== About Touchatag ==<br />
<br />
Touchatag is a RFID tag reader from [http://www.touchatag.com/ Touchatag]. It is a cheap set consisting of an ACR122U USB tag reader and MiFare Ultralight RFID tags.<br />
<br />
It is available [http://www.touchatag.com/e-store here] or for Europe [http://www.getdigital.de/products/Touchatag/lng/en here].<br />
<br />
'''Remember: Always put a tag on the reader, otherwise you might encounter problems!'''<br />
<br />
== Check hardware version ==<br />
<br />
lsusb shows the device:<br />
<br />
Bus 003 Device 004: ID 072f:2200 Advanced Card Systems, Ltd <br />
<br />
lsusb -v shows also the firmware version bcdDevice:<br />
<br />
idVendor 0x072f Advanced Card Systems, Ltd<br />
idProduct 0x2200 <br />
bcdDevice 1.00<br />
<br />
The Version this howto is about is the above ACS ACR122U PICC firmware 1.0.<br />
<br />
== Install Touchatag ==<br />
<br />
First install this:<br />
# pacman -S pcsclite pcsc-tools pcsc-perl ccid<br />
<br />
=== Install pcsclite-libudev ===<br />
<br />
The normal pcsclite package from the community repository uses libusb instead of udev, which causes problems when using the Touchatag reader. So we need to replace it with the [https://aur.archlinux.org/packages.php?ID=49245 pcsclite-libudev] package from AUR:<br />
# cd /tmp<br />
# wget https://aur.archlinux.org/packages/pcsclite-libudev/pcsclite-libudev.tar.gz<br />
# tar -xf pcsclite-libudev.tar.gz<br />
# cd pcsclite-libudev<br />
# makepkg<br />
# sudo pacman -U pcsclite-libudev-*.pkg.tar.xz<br />
<br />
=== Install the ACS CCID PC/SC driver ===<br />
<br />
Install the [https://aur.archlinux.org/packages.php?ID=49246 acsccid] package from AUR:<br />
# cd /tmp<br />
# wget https://aur.archlinux.org/packages/acsccid/acsccid.tar.gz<br />
# tar -xf acsccid.tar.gz<br />
# cd acsccid<br />
# makepkg<br />
# sudo pacman -U acsccid-*.pkg.tar.xz<br />
<br />
With old versions of the ACS driver, you can get errors like these:<br />
<br />
ifdhandler.c: In functie ‘IFDHControl’:<br />
ifdhandler.c:1304:8: fout: ‘PIN_PROPERTIES_STRUCTURE’ has no member named ‘wLcdMaxCharacters’<br />
ifdhandler.c:1305:8: fout: ‘PIN_PROPERTIES_STRUCTURE’ has no member named ‘wLcdMaxLines’<br />
<br />
In such a case, you can try commenting out those to lines in src/ifdhandler.c.<br />
<br />
== Test Touchatag ==<br />
<br />
Try to scan your Touchatag:<br />
<br />
# pcsc_scan<br />
<br />
You should get something like this:<br />
<br />
PC/SC device scanner<br />
V 1.4.17 (c) 2001-2009, Ludovic Rousseau <ludovic.rousseau@free.fr><br />
Compiled with PC/SC lite version: 1.6.6<br />
Scanning present readers...<br />
0: ACS ACR122U 00 00<br />
<br />
Mon Mar 21 18:16:07 2011<br />
Reader 0: ACS ACR122U 00 00<br />
Card state: Card inserted, Shared Mode, <br />
ATR: 3B BE 95 00 00 41 03 00 00 00 00 00 00 00 00 00 02 90 00 <br />
<br />
ATR: 3B BE 95 00 00 41 03 00 00 00 00 00 00 00 00 00 02 90 00<br />
+ TS = 3B --> Direct Convention<br />
+ T0 = BE, Y(1): 1011, K: 14 (historical bytes)<br />
TA(1) = 95 --> Fi=512, Di=16, 32 cycles/ETU<br />
125000 bits/s at 4 MHz, fMax for Fi = 5 MHz => 156250 bits/s <br />
TB(1) = 00 --> VPP is not electrically connected<br />
TD(1) = 00 --> Y(i+1) = 0000, Protocol T = 0 <br />
-----<br />
+ Historical bytes: 41 03 00 00 00 00 00 00 00 00 00 02 90 00<br />
Category indicator byte: 41 (proprietary format) <br />
<br />
Possibly identified card (using /usr/share/pcsc/smartcard_list.txt):<br />
3B BE 95 00 00 41 03 00 00 00 00 00 00 00 00 00 02 90 00<br />
touchatag SAM card<br />
<br />
If you encounter a problem like this:<br />
<br />
# pcscd -f<br />
<br />
ccid_usb.c:859:ccid_check_firmware() Firmware (1.00) is bogus! Upgrade the reader firmware or get a new reader.<br />
ifdhandler.c:104:IFDHCreateChannelByName() failed<br />
readerfactory.c:1050:RFInitializeReader() Open Port 200000 Failed (usb:072f/2200:libusb:006)<br />
readerfactory.c:233:RFAddReader() ACS ACR122U PICC Interface init failed.<br />
<br />
The [http://code.google.com/p/libnfc/source/browse/trunk/README libnfc README] suggests to do this:<br />
<br />
If your Touchatag or ACR122 device fails being detected by PCSC-lite daemon (pcsc_scan doesn't see anything) <br />
then try removing the bogus firmware detection of libccid: edit libccid_Info.plist configuration file <br />
(usually /etc/libccid_Info.plist) and locate "<key>ifdDriverOptions</key>", turn "<string>0x0000</string>" <br />
value into 0x0004 to allow bogus devices and restart pcscd daemon.<br />
<br />
Warning: if you use ACS CCID drivers (acsccid), configuration file is located in something like: <br />
/usr/lib/pcsc/drivers/ifd-acsccid.bundle/Contents/Info.plist<br />
<br />
== Install tagEventor ==<br />
<br />
[http://code.google.com/p/tageventor/ tagEventor] runs in the background and executes scripts when a tag enters or leaves your tag reader.<br />
<br />
Download a [http://code.google.com/p/tageventor/downloads/list binary version] or [http://code.google.com/p/tageventor/source/checkout compile] your own.<br />
<br />
Run tagEventor to test your installation:<br />
<br />
# tagEventor -v 1<br />
<br />
The scripts are located in /etc/gtagEventor. Read the [http://code.google.com/p/tageventor/ tagEventor documentation] on how to use them.</div>Hardfalcon