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

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

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.

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

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.

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.

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

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.

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 !)

1

umask 077

2

mkdir -p ~/.ssh

3

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

1

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:

1

Host pi1

2

        HostName 192.168.143.1

3

        User root

4

        IdentityFile ~/.ssh/id_rsa

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

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

1

ssh pi1 # interaktive Shell

2

ssh pi1 ls -l # listed files auf

3

scp localfile pi1:~/remotedir # kopiert Datei auf remote pi1

Michael

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

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

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.

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?

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.

Le X. schrieb:

Was ist denn an telnet einfacher?

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

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.

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.

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

1

/tmp$ ssh-keygen -f schlüsseldatei

2

3

Generating public/private rsa key pair.

4

Enter passphrase (empty for no passphrase): 

5

Enter same passphrase again: 

6

Your identification has been saved in schlüsseldatei

7

Your public key has been saved in schlüsseldatei.pub

8

The key fingerprint is:

9

SHA256:QiUxJb06uUG8DuOs32XTy4Bb0F0LfeieM76mkd19Zuk norbert@Entwicklung

10

The key's randomart image is:

11

+---[RSA 3072]----+

12

|      =+o        |

13

|       =.  . .   |

14

|     ..  .. + .  |

15

|     .o... + o   |

16

|     .o+S . o    |

17

|    o *+ . + o ..|

18

|   o +.+* + * ..=|

19

|    o.o= + +.o.o.|

20

|  .o. o   +oo. E |

21

+----[SHA256]-----+

22

23

/tmp$ l schlüsseldatei*

24

-rw------- 1 norbert norbert 2610  2. Jan 11:47 schlüsseldatei

25

-rw------- 1 norbert norbert  573  2. Jan 11:47 schlüsseldatei.pub

Norbert schrieb:

1

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

1

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

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.