SSH FIDO2/U2F Token auth für Debian buster

Ich warte schon seit dem release von OpenSSH 8.4 darauf endlich den neuen security token support auf meinen Debian stable servern verwenden zu können. Eigendlich hatte ich gemeint da werde ich wohl auf buster+1 (bullseye) warten müssen, aber heute ist mir dann aufgefallen dass es einen backport für buster gibt!

Nach schnellem testen war klar das funktioniert tatsächlich, und ab damit auf alle server. Inklusive und vorallem ITS relevant: der (hyper)root account auf der parabox.

Debian backports produktiv verwenden

Debian backports zu verwenden kann aber so eine sache sein wenn man nicht genau weiß was man tut. Ein unerfahrener admin würde evtl. versuchen das repo einfach in die sources.list einzutragen, und wenn man glück hat, hat er die optionen apt-get install -t buster-backports pkg oder apt-get install pkg/buster-backports schon mal gesehen und verwendet die. Bei diesem vorgehen kann man dann aber eines von zwei problemen haben:

Es kann sein dass die install aus backports nur einmal funktioniert aber ab dem punkt an von apt keine updates aus backports angenommen werden. Eine lösung dafür ist (leider) apt pinning mit dem preferences file. Siehe man apt_preferences. Pinning kommt aber mit seiner eigenen reihe an gotchas, aber solange es sich nur auf openssh beschränkt ist es garnicht so schlimm.

Effektiv braucht man zusätzlich zur debian-backports zeile im sources.list einfach folgende zwei config files:

/etc/apt/sources.list:

deb http://deb.debian.org/debian buster-backports main

/etc/apt/preferences:

Package: openssh-* libfido2-1
Pin: release a=buster-backports
Pin-Priority: 999

Package: *
Pin: release a=buster-backports
Pin-Priority: -10

Damit sagen wir apt es soll openssh und libfido2 dependency aus dem buster-backports repo über die paket versionen aus dem “normalen” repo bevorzugen aber sonst alle pakete in backports ignorieren. Was den nun das “normale” repo ist sagen wir apt dann so:

/etc/apt/apt.conf.d/99its-default-release:

APT::Default-Release "buster";

Hier kommt dann das zweite problem zu trage. Je nach dem wie man sein Debian system aufgesetzt hat, hat man so einen default-release eintrag schon oder auch nicht. Der normale Debian installer sollte das als eigenes 99-default-release file installieren. Oft setze ich zumindest systeme auch über debootstrap(1) manuell auf, das Hetzner installer system scheint das auch so zu machen und hat dadurch von selber auch keinen default release gesetzt.

Das problem mit dem fehlenden default release ist dass apt dann neuere versionen von allen paketen aus backports einfach verwenden würde obwohl wir das lieber pro-paket freischalten würden. Der Pin-Priority: -10 eintrag oben sollte aber auch diesen fall abfangen. Trozdem ist es besser den default release zu setzen.

Nach dem ganzen reicht dann ein apt-get full-upgrade und wir haben die neue openssh version.

NB: Wir brauchen full-upgrade weil die neue version pakete installieren muss die es davor noch nicht gegeben hat und ein reines upgrade vermeidet das per default. Das kann man auch mit APT::Get::Upgrade-Allow-New abschalten, das ist aber ein anderes thema.

Bei openssh sollte das auch bei automatischen upgrades nicht zum problem werden weil das so oder so schon sehr wenige dependencies hat und in Debian allgemein die policy gilt dass pakete in eienm release nur zielgerichtete fixes bekommen und nicht auf neue upsteam versionen geupdated werden. Natürlich gibt es hier auch ausnahmen: chromium lässt grüßen.

Token basierte SSH keys generieren

Wenn wir die richtige openssh version mal haben ist alles eigendlich ganz einfach:

  1. Token einstecken,
  2. ssh-keygen -t ecdsa-sk -f ~/.ssh/id_ecdsa_sk,
  3. Token button drücken und
  4. Passphrase sollte man setzen um wirklich zwei faktor authentifizierung zu bekommen.

Das ~/.ssh/id_ecdsa_sk ist die default location in der ssh dann beim login auch sucht, so wie für id_rsa und co. Da muss man dann kein IdentityFile in der .ssh/config für die server konfigurieren auf denen man das verwendet.

Aus dem prozedere fällt dann wie gewohnt ein ~/.ssh/id_ecdsa_sk.pub raus das man dann auf den servern verteilen kann.

1 Like

Ein problem mit dem setup is mir jetzt noch aufgefallen. Ein reines full-upgrade reicht nicht weil die neue ssh version auch libfido2 aus backports braucht, man muss wirklich die apt-get install -t buster-backports variante machen damits geht.

Das paket muss einfach auch noch gepinnt werden, eigendlich allein schon weil es sonst auch keine upgrades bekommt. Muss das noch testen dann update ich das.

Gestern war der bullseye release (Yay!) das hat jetzt aber die Default-Release zeile gebrochen weil das jetzt "oldstable" is :slight_smile:

Scheint also doch besser zu sein da den expliziten release namen zu verwenden.

1 Like

Zeit mal die neue Ssd um Privatlaptop zu verbauen.

Please be advised: Chapter 5. Issues to be aware of for bullseye. Bei einem upgrade von dieser Default-Release konfiguration von buster auf bullseye funktionieren security updates dann nicht mehr.