SSH ohne passwort

[Otto123]

Hallo Achim,

ich kann momentan nichts testen da ich unterwegs bin.
Aber ich lese jetzt folgendes:
Der Windows User stimmt und kann sich anmelden
ssh Zugang funktioniert prinzipiell mit Passwort.
Dein fhem Account hat einen Key.
Der Windows Server akzeptiert aber nicht wenn User fhem seinen Key für user micro präsentiert.
Hast Du den Key von User fhem (Linux) auf den User micro (Windows) auch erfolgreich übertragen?
Ich hatte hier nochmal einen komprimierten Artikel gemacht.
Kannst Du nochmal überprüfen (als User fhem)!?

Code Auswählen Erweitern

ssh-copy-id -i ~/.ssh/id_rsa micro@192.168.222.26

Gruß Otto

[Dia81]

ich hänge mich auch mal wieder dran

Brauche SSH um ein Ipad aufzuwecken habe auch nach deiner Anleitung alles gemacht und komme auch per Verbindung auf das andere Geät, nur muss ich jedesmal den Schlüssel neu eingeben obwohl ich auf den fhem user gewechselt habe.
Da das noch ganz neue Materie ist für mich, weiss ich nicht wo ich ansetzen muss, welche Info ihr braucht oder wie es weitergeht.

Ziel soll sein ein Bewegungsmelder bei Motion das IPAD aufzuwecken. Der Befehl geht auch per Shell, allerdings immer mit der ensprechenden Eingabe des "Passworts".

Nun prügel auf mich ein :>

[Otto123]

nur muss ich jedesmal den Schlüssel neu eingeben

Was genau meinst Du damit? Das Passwort?

BTW: Ich habe keine Ahnung ob und wie das bei einem iPad wirklich geht? Wo hat der ssh Server beim iPad seinen Speicherort für die Schlüssel? Beim Userpfad? Beim Serverpfad wie bei dropbear?

Gruß Otto

[Dia81]

Was genau meinst Du damit? Das Passwort?

BTW: Ich habe keine Ahnung ob und wie das bei einem iPad wirklich geht? Wo hat der ssh Server beim iPad seinen Speicherort für die Schlüssel? Beim Userpfad? Beim Serverpfad wie bei dropbear?

Gruß Otto

Ich erzeuge den Schlüssel ja durch Eingabe einer Phrase oder eines Passwortes. Dieses wird verlangt wenn ich den ssh Befehl Richtung iPad abschicke. Nach Eingabe bin ich als Root auf dem ipad. Der Befehl den ich brauche um den bildschirm zu entsperren kann ich als Fhem User in der Shell eingeben. Das funktioniert auch , das iPad entsperrt und geht an, aber ich muss halt die Phrase eingeben.

Wo da was gespeichert wird weiß ich leider nicht , habe das einfach nach deiner verlinkten Anleitung gemacht. Geht nur mit einem gejailbreakten iPad und ein paar Einstellungen. Kann gerne das Tutorial dazu morgen verlinken. Da ich damit durch homematic Bewegungsmeldern den Bildschirm anschalten lassen kann könnte ich mein altes iPad nehmen und dadurch das viel ältere schrottige und langsame Android ersetzten für Anzeige von tablet ui. Das geht aber nur wenn ich aus fhem den Befehl ohne Phrase Angabe absetzen kann ....

[Dia81]

Hier der link doch noch :

http://www.bastelbudenbuben.de/2017/03/21/ipad-1-mit-jailbreak-als-steuerzentrale-in-fhem-einbinden/

[Otto123]

Ich erzeuge den Schlüssel ja durch Eingabe einer Phrase oder eines Passwortes.

Aber genau das wäre der Fehler!
Du musst einen Schlüssel ohne Passphrase erstellen, so steht es auch in meiner Anleitung!
Mit PassPhrase hast Du so keine Chance, das geht dann eventuell mit irgendeinem Tool - was ich aber für nicht zielführend halte.

Gruß Otto

[Dia81]

Aber genau das wäre der Fehler!
Du musst einen Schlüssel ohne Passphrase erstellen, so steht es auch in meiner Anleitung!
Mit PassPhrase hast Du so keine Chance, das geht dann eventuell mit irgendeinem Tool - was ich aber für nicht zielführend halte.

Gruß Otto

Okay dann Versuch ich das nochmal und hoffe ich kann das dann quasi ,,überschreiben ,,

[CBSnake]

Kannst Du nochmal überprüfen (als User fhem)!?

Code Auswählen Erweitern

ssh-copy-id -i ~/.ssh/id_rsa micro@192.168.222.26

Gruß Otto

Hallo Otto,
den Befehl mag er nicht:

Code Auswählen Erweitern

fhem@raspberrypi:/home/pi$ ssh-copy-id -i ~/.ssh/id_rsa micro@192.168.222.26
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/opt/fhem/.ssh/id                        _rsa.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter                         out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompt                        ed now it is to install the new keys
micro@192.168.222.26's password:
Der Befehl "exec" ist entweder falsch geschrieben oder
konnte nicht gefunden werden.
Das System kann den angegebenen Pfad nicht finden.


Die Abfolge aus deiner Anleitung:

Code Auswählen Erweitern

ziel=user@host              # Benutzer und Host einmal eintragen
#### Linux System
ssh-copy-id -i ~/.ssh/id_rsa $ziel
#### Windows System
scp ~/.ssh/id_rsa.pub $ziel:key.tmp

geht allerdings und ergibt:

Code Auswählen Erweitern


fhem@raspberrypi:/home/pi$ ziel=micro@192.168.222.26
fhem@raspberrypi:/home/pi$ scp ~/.ssh/id_rsa.pub $ziel:key.tmp
micro@192.168.222.26's password:
id_rsa.pub                                                            100%  398    49.0KB/s   00:00



Die Datei authorized_keys auf dem Windows Rechner ist danach aktualisiert und enthält den Key aus id_rsa.pub vom fhem user auf dem Raspberry

[CBSnake]

So, habs gelöst 

micro@.... ist admin, dann gelten besondere Regeln unter Windows 

@otto hier mal die Anleitung die zusätzlich nötig ist

https://www.concurrency.com/blog/may-2019/key-based-authentication-for-openssh-on-windows

die administrators_authorized_keys ins angegebene Verzeichnis

unter Windows Powershell als Admin starten und dann:

Code Auswählen Erweitern



$acl = Get-Acl C:\ProgramData\ssh\administrators_authorized_keys
$acl.SetAccessRuleProtection($true, $false)
$administratorsRule = New-Object system.security.accesscontrol.filesystemaccessrule("Administrators","FullControl","Allow")
$systemRule = New-Object system.security.accesscontrol.filesystemaccessrule("SYSTEM","FullControl","Allow")
$acl.SetAccessRule($administratorsRule)
$acl.SetAccessRule($systemRule)
$acl | Set-Acl



Grüße
Achim

[Otto123]

Hallo Achim,

sorry für den Fehler in #15 - klar ssh-copy-id geht da nicht.

Zum Administrator Problem: Das muss ich nochmal durchdenken, aber ich meine in dem Artikel in deinem Link wird nur ein alternativer Lösungsansatz verwendet?
Schau mal hier in meinen Artikel https://heinz-otto.blogspot.com/2019/05/windows-von-fhem-aus-steuern.html weiter hinten bei Eigenheiten Windows Server 2012.

Bei Windows 10 hatte ich dieses Verhalten noch nicht. Welche Version hast Du genau installiert? Home oder pro De oder EN mit MUI?

Kannst Du mal den Inhalt der C:\ProgramData\ssh\sshd_config posten? Da steht nichts Systemspezifisches drin.

Vielleicht ist auch die sshd Version aktuell geändert?

Gruß Otto

[CBSnake]

Hi Otto,

ich hab die Pro und ich denke keine EN MUI

Code Auswählen Erweitern

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options override the
# default value.

#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

#HostKey __PROGRAMDATA__/ssh/ssh_host_rsa_key
#HostKey __PROGRAMDATA__/ssh/ssh_host_dsa_key
#HostKey __PROGRAMDATA__/ssh/ssh_host_ecdsa_key
#HostKey __PROGRAMDATA__/ssh/ssh_host_ed25519_key

# Ciphers and keying
#RekeyLimit default none

# Logging
#SyslogFacility AUTH
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
#PermitRootLogin prohibit-password
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

#PubkeyAuthentication yes

# The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2
# but this is overridden so installations will only check .ssh/authorized_keys
AuthorizedKeysFile .ssh/authorized_keys

#AuthorizedPrincipalsFile none

# For this to work you will also need host keys in %programData%/ssh/ssh_known_hosts
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no

#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
#PermitTTY yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#PermitUserEnvironment no
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS no
#PidFile /var/run/sshd.pid
#MaxStartups 10:30:100
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum none

# no default banner path
#Banner none

# override default of no subsystems
Subsystem sftp sftp-server.exe

# Example of overriding settings on a per-user basis
#Match User anoncvs
# AllowTcpForwarding no
# PermitTTY no
# ForceCommand cvs server

Match Group administrators
       AuthorizedKeysFile __PROGRAMDATA__/ssh/administrators_authorized_keys

Der letzte Eintrag wäre dann wohl zum auskommentieren

Grüße
Achim

[Otto123]

Ja

Ok ich sehe ich muss meinen Ablauf neu testen. Wahrscheinlich hat das nichts mit der Windows Version zu tun sondern mit der OpenSSH Version.
Ich muss da nochmal tiefer "graben"

Ich melde mich zurück wenn ich mehr weiß.

Gruß Otto

[Otto123]

Hi,

es ist etwas "verrückter" als ich vermutet habe. Ich hatte kurz an mir gezweifelt ...
Ich weiß noch nicht ob man Bug oder Feature dazu sagen soll

Ich habe nicht alle Kombinationen getestet, aber kann folgendes sagen:

• Windows 10 Version 1803 enthält eine Datei C:\ProgramData\ssh\sshd_config ohne den Abschnitt "Match Group administrators ..." ganz am Ende.
• Windows 10 Version 2004 (und 20H2) enthält eine Datei C:\ProgramData\ssh\sshd_config mit den Abschnitt "Match Group administrators ..." ganz am Ende.

Ich dachte bisher: Der Start des Update durch "Setup" von der DVD/ dem ISO Image Windows 10, welches man mit dem MediaCreationToolxxxx erhält, liefert das gleiche Ergebnis wie das Versions Update welches einem irgendwann angeboten wird bzw. durch den "Windows 10-Update-Assistent" erzwungen werden kann. Beide Tools kann man hier herunterladen.
Dem ist nicht so! Zumindest wird durch ersteres der sshd Service wieder entfernt die Datei C:\ProgramData\ssh\sshd_config bleibt aber zunächst erhalten. Man muss den Service neu installieren.

Egal wie man dazu kommt, die Datei C:\ProgramData\ssh\sshd_config wir in der neuer Version (mindestens ab 2004) so verändert, das die Anmeldung der Gruppe Administratoren per ssh (über den Weg homedir/.ssh/ ) unterbunden wird.
Die OpenSSH Version ist in jeder Version die gleiche: OpenSSH.Server~~~~0.0.1.0
Dieser Powershell Code behebt das "Problem" der Anmeldung von Administratoren über ssh.Edit: Achtung: in administrativer Powershell ausführen

Code Auswählen Erweitern

# Patch sshd config to allow administrators Group public Key logon
$Quelle="${Env:ProgramData}\ssh\sshd_config"
write-output "patch the sshd config on $Quelle"
Stop-Service -Name sshd
$Inhalt = Get-Content $Quelle
#search 2 lines contains administrators and insert commment sign
$Inhalt|foreach {if ($_ -match "administrators") {$Inhalt[$_.readcount-1]=$_.Insert(0,"#")}}
set-Content $Quelle $Inhalt
Start-Service -Name sshd

Ich muss nochmal über die Variante "Feature" oder "Fehlerkorrektur" nachdenken: Was bedeutet es, wenn man für die Gruppe der Administratoren eine gemeinsame administrators_authorized_keys Datei unterhalb von C:\ProgramData\ssh\ pflegt?

Gruß Otto

[CBSnake]

Moin,

nachdem FHEM vom PI auf den Debian Server zog war natürlich die "Anmeldung" am Windowsrechner futsch Hab deinen Powershell Patch daher gleich mal probiert (Wichtig: als Admin ausführen und tada klappt prima

Dankeschön

Grüße
Achim