macOS: SSH Hosts mit Autovervollständigung aufrufen

Es gibt unter macOS Mojave keine Autovervollständigung der definierten Hosts aus der Datei ~/.ssh/config. Hierzu habe ich in die Datei ~/.bash_profile folgende Funktion eingetragen :

function __completeSSHHosts {
	COMPREPLY=()
	local currentWord=${COMP_WORDS[COMP_CWORD]}
	local completeHosts=$(
		cat "$HOME/.ssh/config" | \
			grep --extended-regexp "^Host +([^* ]+ +)*[^* ]+ *$" | \
			tr -s " " | \
			sed -E "s/^Host +//"
	)

	COMPREPLY=($(compgen -W "$completeHosts" -- "$currentWord"))
	return 0
}

complete -F __completeSSHHosts ssh

Nun reicht wieder ein ssh TAB in der Konsole um die einzelnen Hosts und der damit verbundenen Konfiguration aufzurufen.

Debian Squeeze: SSH zwei Stufenauthentifizierung mit google-authenticator

Ich habe vor ein paar Tagen mit dem Artikel „Google macht SSHD sicher“ über einen Artikel aus meinem Feedreader berichtet. Nun habe ich das ganze selbst ausgetestet und bin begeistert.

The Google Authenticator project includes implementations of one-time passcode generators for several mobile platforms, as well as a pluggable authentication module (PAM). One-time passcodes are generated using open standards developed by the Initiative for Open Authentication (OATH) (which is unrelated to OAuth).

These implementations support the HMAC-Based One-time Password (HOTP) algorithm specified in RFC 4226 and the Time-based One-time Password (TOTP) algorithm currently in draft.

Vorab zur Information:
– In den Sourcen des Modules für PAM gibt es keinerlei Kontaktaufnahme zu einem Google-Server
– Der einzige Aufruf befindet sich in der Datei ./google-authenticator.c um einen QR-Code zu generieren, dazu später mehr
– Die Androidapp nimmt kein Kontakt in das Netz auf, das einzige was sie möchte ist vibrieren.
– Wenn kein Zugang zu dem Smartphone besteht hat man noch Emergency Scratchcodes.
– Die Software ist eine Erweiterung der Sicherheit des sshd und es sollte nicht sonst ein passwortloser Login erlaubt werden

Ich gehe davon aus, dass der openssh-server und Compiler installiert sind.

root@xbmc:~/# mkcd ga
 root@xbmc:~/ga# aptitude install mercurial libpam0g-dev -y
 root@xbmc:~/ga# hg clone  google-authenticator
 cd google-authenticator/libpam/
 root@xbmc:~/ga/google-authenticator/libpam# make
 root@xbmc:~/ga/google-authenticator/libpam# make install

cp pam_google_authenticator.so /lib/security
 cp google-authenticator /usr/local/bin
 sudo chmod 755 /lib/security/pam_google_authenticator.so 
 /usr/local/bin/google-authenticator

Da wir uns nicht als root per ssh anmelden, so etwas gehört sich nicht, nehmen wir substitude user und wechseln den Account zur generieren des Codes:

root@xbmc:~/ga/google-authenticator/libpam# su seraphyn
 seraphyn@xbmc:/root/ga/google-authenticator/libpam$ google-authenticator
 https://www.google.com/chart?chs=200x200&chld=ETCETCETCETC
 Your new secret key is: BLABLABLABLA
 Your verification code is NUMBERSNUMBERSNUMBERS
 Your emergency scratch codes are:
 MORENUMBERS

Do you want me to update your "~/.google_authenticator" file (y/n) y

Do you want to disallow multiple uses of the same authentication
 token? This restricts you to one login about every 30s, but it increases
 your chances to notice or even prevent man-in-the-middle attacks (y/n) y
 seraphyn@xbmc:/root/ga/google-authenticator/libpam$ exit

Nicht vergessen die ganze Ausgabe abzuspeichern, denn die URL und vor allen die Codes werden später noch gebraucht.
Ich gehe nicht davon aus, dass auf einem Server eine GUI ist.

Jetzt müssen nur noch der SSH-Server und PAM konfiguriert werden um Google Authentication zu nutzen.
In der Datei /etc/pam.d/sshd muss noch pam_google_authenticator.so hinzugefügt werden:

# /etc/default/locale, so read that as well.
 auth required pam_env.so envfile=/etc/default/locale
 auth required pam_google_authenticator.so

und in der Datei /etc/ssh/sshd_config das Challenge-Response-Verfahren aktiviert werden:

# Change to yes to enable challenge-response passwords (beware issues with
 # some PAM modules and threads)
 ChallengeResponseAuthentication yes

Nach der Installation von Google Authenticator auf Android startet man diesen.
Wenn man die aus der Shell generiert URL in seinem Desktopbrowser aufruft bekommt man einen QR-Code, welcher mit dem auf Android installiertem Google Authenticator per Menü > Scan account barcode ausgelesen wird.
Der 6stellige Code generiert sich alle 30 Sekunden neu und man kann in Ruhe die App auflassen und sich davon überzeugen ツ
Auf der Maschine die nun pam-google-authenticator nutzt kann der SSH-Server neu gestartet werden.
Beim erneuten Einloggen erscheint nun:

Verification code:
 Password:

Als erstes soll man den auf dem Smartphone angegebenen Code eingeben, danach das normale Passwort.
Wenn nun das Smartphone nicht vorhanden ist, dann kann einer der 6 emergency scratch codes genommen werden.

Achtung: Falls der User keinen generierten Schlüssel in seinem $HOME hat (.google_authenticator) wird dieser nicht der Zweistufenauthenifizierung unterzogen.

Google macht SSHD sicher

Ich kann mich noch daran erinnern wie ich damals den RSA-Schlüsselanhänger implementiert habe.
Tolle Sache diese SecureID. Man hat einen Schlüsselanhänger mit, ach was Erkläre ich das Wikipedia EN: SecureID.
Auf jeden Fall es hat mich fasziniert und ich gebe das gerne immer als Sicherheitstip weiter, das inkl eines Passwortes, welche noch angegeben werden muss als relativ Okay empfinde. Auch wenn es schon Attacken dagegen gab.
Komisch, ich weiss, aber Hey, besser als wenn die User nur ein Passwort haben und das PostIT und Konsortengerecht verteilt, Ihr wisst schon.
Nun hat Google seine Zweifaktorauthentifizierung für Jedermann freigegeben.
Ich habe eine Anleitung Heute in meinem Feedreader gehabt, welche erklärt wie man mit Hilfe von PAM ( Pluggable Authentification Module, ich mag das, damit kann man einiges machen, z.B. Gesichtserkennung für einen Login etc) und einem Smartphone die Authentifizierung durchführen kann.
Ich werde das Ganze mal auf Debian Squeeze testen und mir die Sourcen anschauen.
Denn irgendwie hat man schon ein komisches Gefühl Google an sein PAM zu lassen. Aber fasziniert bin ich von dieser Sache und denke mir Passwort, Key und das Googlepamplugin zusammen sind eine wirklich gute Idee.

Turning on 2-step verification: Installing Google Authenticator
The application doesn’t require an Internet connection, mobile service, or a data plan to generate verification codes.

Debian Squeeze: Redseliges SSH

Was mir bei vielen Paketen einfach nicht gefällt ist ein Faktor:

seraphyn@sayuri:~$ nmap -sV 192.168.1.1

Starting Nmap 5.00 ( http://nmap.org ) at 2011-02-07 09:58 CET
 Interesting ports on 192.168.1.1:
 Not shown: 996 filtered ports
 PORT STATE SERVICE VERSION
 22/tcp open ssh OpenSSH 5.5p1 Debian 6 (protocol 2.0)

Wer dies absolut nicht verknusen kann, welches ich verstehe, sollte sich mal die Datei /debian/patches/debian-banner.patch aus den openssh-server-Sourcen anschauen und das Paket recompilieren.
Das ganze basiert auf den Bugreport #562048, welches schon etwas weniger über das darunterliegende Linux aussagt.
Natürlich ist es auch möglich absolut die Version von dem openssh-Server zu verstecken, aber einen sinn hat dies nicht, siehe dazu auch:
RFC: The SSH (Secure Shell) Remote Login Protocol

und

OpenSSH-FAQ: 2.14 Why does OpenSSH report its version to clients?
This information is used by clients and servers to enable protocol compatibility tweaks to work around changed, buggy or missing features in the implementation they are talking to. This protocol feature checking is still required at present because the SSH protocol has not been yet published as a RFC and more incompatible changes may be made before this happens.

IMHO ist der Rest Security Through Obscurity und hat keinen Sinn.
Lieber den Server richtig sicher machen, dazu gibt es genug Anleitungen im Netz….