Mac: SSH-Session per Terminal mit einer CLI-Eingabe?

[Frank E. (Firma: Q3) (qualidat)]

Wenn ich vom Mac aus eine SSH-Verbindung zu einem Raspberry öffnen will, 
öffne ich das Terminal und geb: "ssh pi@192.168.x.y" ein, dann werde ich 
noch zur Eingabe des Passworts aufgefordert und "ich bin drin".

Frage nun: Ist es auch möglich, den gesamten Anmeldevorgang mit EINEM 
einzeiligen Cli-Kommando auszuführen, also ohne nachträgliche 
Interaktion (Passworteingabe)?

[Michael D. (nospam2000)]

Frank E. schrieb:
> Frage nun: Ist es auch möglich, den gesamten Anmeldevorgang mit EINEM
> einzeiligen Cli-Kommando auszuführen, also ohne nachträgliche
> Interaktion (Passworteingabe)?

Ja, am besten mit publickey Authentifizierung.

Siehe ssh-keygen, ~/.ssh/config und ~/.ssh/authorized keys als 
Suchbegriffe, z.B. hier:
https://www.digitalocean.com/community/tutorials/how-to-configure-ssh-key-based-authentication-on-a-linux-server

 Michael

[Stephan S. (uxdx)]

Michael D. schrieb:
> Ja, am besten mit publickey Authentifizierung.

Aber auch da wird (einmalig je Sitzung) ein Passwort zur Freigabe des 
PublicKey verlangt. Es sei denn, das Passwort ist leer, aber das ist 
dann wieder unsicher.

[Michael D. (nospam2000)]

Stephan S. schrieb:
> Aber auch da wird (einmalig je Sitzung) ein Passwort zur Freigabe des
> PublicKey verlangt. Es sei denn, das Passwort ist leer, aber das ist
> dann wieder unsicher.

ssh-agent ist dein Freund, dann musst du nur einmal dein Passwort 
eingegeben pro Rechner-Start. Das ist natürlich unsicherer wie es jedes 
mal einzugeben.

"sh-agent is a program to hold private keys used for public key 
authentication.  Through use of environment variables the agent can be 
located and automatically used for authentication when logging in to 
other machines using ssh(1)."

Was willst du:
 - Sicherheit
 - Bequemlichkeit

Such dir eines der beiden aus. "There is no free lunch"...

Oder wie es ein Kollege einmal formuliert hat:
"Security ist nicht dazu da einem das Leben einfacher zu machen"

 Michael

[Michael H. (mha1)]

Das Passwort für den Private Key kann man bei MacOS mit ssh-add und den 
Optionen --apple-use-keychain und --apple-load-keychain in der Keychain 
speichern (alte MacOS Version -K und -A). Dann muss man das Passwort 
nicht jedesmal eingeben.

[Norbert (der_norbert)]

Stephan S. schrieb:
> Aber auch da wird (einmalig je Sitzung) ein Passwort zur Freigabe des
> PublicKey verlangt. Es sei denn, das Passwort ist leer, aber das ist
> dann wieder unsicher.

So wie der ursprüngliche Wunsch es auch ist.
Nur: Oftmals wird ganz einfach keine Sicherheit gewollt und auch nicht 
gebraucht.

[Michael D. (nospam2000)]

Norbert schrieb:
> So wie der ursprüngliche Wunsch es auch ist.
> Nur: Oftmals wird ganz einfach keine Sicherheit gewollt und auch nicht
> gebraucht.

Genau: die Sicherheit muss dem Schutzziel entsprechen. Wenn jemand 
meinen Wetterdatenlogger hackt, dann passiert da nichts außer dass ich 
den neu installieren muss.

@Frank E.
Du kannst auch einen Fido 2 Key verwenden wenn das für dich besser 
passt. Du solltest nur sicherstellen, dass bei einem Verlust oder Defekt 
du trotzdem wieder an das System rankommst ggf. über eine lokale 
console.

 Michael

[Frank E. (Firma: Q3) (qualidat)]

Es handelt sich um zwei Dutzend Raspis, die in einem Museum interaktive 
Exponate steuern. Die befinden sich alle in einem eigenen Subnet, das 
ich nur per VPN erreichen kann. Das Sicherheitsbedürfnis hält sich also 
in überschaubaren Grenzen.

Von dem Vorschlag mit public key habe ich schon gehört. Erfordert das 
zusätzliche Installationen auf den Raspis? Muss ich mich belesen ...

Also die bisherige Kommandozeile einfach irgendwie um einen Parameter 
mit Passwort erweitern geht nicht? Das wäre für mich am Einfachsten, 
auch wegen der Anzahl der Raspis.

[Michael D. (nospam2000)]

Frank E. schrieb:
> Erfordert das
> zusätzliche Installationen auf den Raspis?

Nein, du musst auf dem Server nur zwei Dinge machen:
1. für jeden User für den du dich einloggen willst das 
~/.ssh/authorized_keys file erzeugen (Achtung: permissions 600 
verwenden, d.h. besten das Kommando `umask 077` eingeben bevor du 
anfängst !)

umask 077
mkdir -p ~/.ssh
echo >~/.ssh/authorized_keys "deinPublicKeyAlsOneLineString"

2. den interactive Password Login deaktivieren nachdem du getestet hast, 
dass der public key login funktioniert.
Bei neueren Debian Distributionen muss du nur eine neue Datei anlegen 
wie mit dem Kommando unten. Bei älteren Installationen (wenn 
/etc/ssh/sshd_config.d nicht existiert) muss man die Datei 
/etc/ssh/sshd_config ändern (ggf. mit sed).
Dieses Kommando muss als root ausgeführt werden, d.h. wenn du noch nicht 
root bist dann `sudo -i` ausführen bevor du das eigentliche Kommando 
ausführts

echo >/etc/ssh/sshd_config.d/disable_password_auth.conf "PasswordAuthentication no"

> Also die bisherige Kommandozeile einfach irgendwie um einen Parameter
> mit Passwort erweitern geht nicht? Das wäre für mich am Einfachsten,
> auch wegen der Anzahl der Raspis.

Ich wüsste nicht wie.

Du musst dich ja nur ein einziges mal auf den Raspis einloggen und die 
Kommandos von oben ausführen.

Auf dem Client für jeden pi einen Eintrag in ~/.ssh/config erzeugen:

Host pi1
        HostName 192.168.143.1
        User root
        IdentityFile ~/.ssh/id_rsa

Die ip und den Filename muss du natürlich anpassen.

Danach kannst du z.B. folgende Kommandos ausführen:

ssh pi1 # interaktive Shell
ssh pi1 ls -l # listed files auf
scp localfile pi1:~/remotedir # kopiert Datei auf remote pi1

 Michael

[Harald K. (kirnbichler)]

Frank E. schrieb:
> Es handelt sich um zwei Dutzend Raspis, die in einem Museum interaktive
> Exponate steuern. Die befinden sich alle in einem eigenen Subnet, das
> ich nur per VPN erreichen kann. Das Sicherheitsbedürfnis hält sich also
> in überschaubaren Grenzen.

Wenn das so ist, könntest Du ja einfach telnet statt ssh verwenden ...

[Frank E. (Firma: Q3) (qualidat)]

Michael D. schrieb:
> Frank E. schrieb:
>> Erfordert das
>> zusätzliche Installationen auf den Raspis?
>
> Nein, du musst auf dem Server nur zwei Dinge machen:
> 1. für jeden User für den du dich einloggen willst das
> ~/.ssh/authorized_keys file erzeugen (Achtung: permissions 600 ...

Vielen Dank für deine Mühe. Ich werde das mal an einem quasi lokalen 
Raspi ausprobieren ...

[Andreas M. (amesser)]

Zum verteilen des keys auf die raspi bietet sich das tool ssh-copy-id 
an. Die ersten drei Punkte wie hier beschrieben:

https://www.ssh.com/academy/ssh/copy-id

Wenn das Sicherheitsbedürfniss nicht allzu hoch ist, dann bei ssh-keygen 
das Passwort leer lassen. Must halt auf den Mac aufpassen, das keiner 
Zugriff drauf hat. Auf die Sicherheit im Netzwerk hat das keine 
Auswirkung.

[Le X. (lex_91)]

Harald K. schrieb:
> Frank E. schrieb:
>> Es handelt sich um zwei Dutzend Raspis, die in einem Museum interaktive
>> Exponate steuern. Die befinden sich alle in einem eigenen Subnet, das
>> ich nur per VPN erreichen kann. Das Sicherheitsbedürfnis hält sich also
>> in überschaubaren Grenzen.
>
> Wenn das so ist, könntest Du ja einfach telnet statt ssh verwenden ...

Was ist denn an telnet einfacher?

[Le X. (lex_91)]

Stephan S. schrieb:
> Michael D. schrieb:
>> Ja, am besten mit publickey Authentifizierung.
>
> Aber auch da wird (einmalig je Sitzung) ein Passwort zur Freigabe des
> PublicKey verlangt. Es sei denn, das Passwort ist leer, aber das ist
> dann wieder unsicher.

Du kannst auch einen Key ohne Passphrase erstellen.
Dann funktioniert es genau so wie es der TE sich wünscht.

[Harald K. (kirnbichler)]

Le X. schrieb:
> Was ist denn an telnet einfacher?

Keine Verschlüsselung, d.h. der ganze Kryptographie-Zertifikatskrempel 
entfällt.

[Stephan S. (uxdx)]

Harald K. schrieb:
> Le X. schrieb:
>> Was ist denn an telnet einfacher?
>
> Keine Verschlüsselung, d.h. der ganze Kryptographie-Zertifikatskrempel
> entfällt.

Und was ist daran einfacher? Sowohl der Raspi als auch der Max haben SSH 
im OS drin.

[Εrnst B. (ernst)]

Harald K. schrieb:
> Keine Verschlüsselung, d.h. der ganze Kryptographie-Zertifikatskrempel
> entfällt.

Aber Passwort muss er trotzdem eintippen. Das entfällt bei SSH mit Key, 
wenn dieser nicht Passwortgeschützt ist.

Für etwas mehr Sicherheit lässt sich der SSH-Key am Mac, wie oben 
Michael geschrieben hatte, auch mit der MacOS-Keychain verbinden. Dann 
ist der SSH-Login mit einem Fingerabdrucks-Scan erledigt.

[Norbert (der_norbert)]

Also ich muss zugeben das SSH ohne Passwort extrem kompliziert ist: ;-)

/tmp$ ssh-keygen -f schlüsseldatei

Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in schlüsseldatei
Your public key has been saved in schlüsseldatei.pub
The key fingerprint is:
SHA256:QiUxJb06uUG8DuOs32XTy4Bb0F0LfeieM76mkd19Zuk norbert@Entwicklung
The key's randomart image is:
+---[RSA 3072]----+
|      =+o        |
|       =.  . .   |
|     ..  .. + .  |
|     .o... + o   |
|     .o+S . o    |
|    o *+ . + o ..|
|   o +.+* + * ..=|
|    o.o= + +.o.o.|
|  .o. o   +oo. E |
+----[SHA256]-----+

/tmp$ l schlüsseldatei*
-rw------- 1 norbert norbert 2610  2. Jan 11:47 schlüsseldatei
-rw------- 1 norbert norbert  573  2. Jan 11:47 schlüsseldatei.pub

[Stephan S. (uxdx)]

Norbert schrieb:

ssh-keygen -f schlüsseldatei

Das erzeugt ein RSA-Schlüsselpaar mit einer Schlüssellänge von 3072 bit, 
das ist z.Zt. noch ok, aber nicht zukunftsträchtig. Besser wäre ein 
Schlüssel mit einer elliptischen Kurve, da ist z.Zt state-of-the-art 
ed25519

ssh-keygen -t ed25519 -a 420 -f schluesseldatei

[Norbert (der_norbert)]

Stephan S. schrieb:
> Das erzeugt ein RSA-Schlüsselpaar mit einer Schlüssellänge von 3072 bit,
> das ist z.Zt. noch ok, aber nicht zukunftsträchtig.

Grundsätzlich stimme ich dir vollkommen zu, jedoch:

Frank E. schrieb:
> Es handelt sich um zwei Dutzend Raspis, die in einem Museum interaktive
> Exponate steuern. Die befinden sich alle in einem eigenen Subnet, das
> ich nur per VPN erreichen kann. Das Sicherheitsbedürfnis hält sich also
> in überschaubaren Grenzen.