Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > ger.ct > #638591 > unrolled thread

ssh keypairs vs. Passwort

Back to article view | Back to ger.ct

Contents

  ssh keypairs vs. Passwort Christian Dürrhauer <cdurrhau@zedat.fu-berlin.de> - 2025-05-21 21:32 +0200
    Re: ssh keypairs vs. Passwort Thomas Hochstein <thh@thh.name> - 2025-05-21 22:58 +0200
      Re: ssh keypairs vs. Passwort Christian Dürrhauer <cdurrhau@zedat.fu-berlin.de> - 2025-05-22 04:38 +0200
        Re: ssh keypairs vs. Passwort Thomas Hochstein <thh@thh.name> - 2025-05-22 08:27 +0200
          Re: ssh keypairs vs. Passwort Christian Dürrhauer <cdurrhau@zedat.fu-berlin.de> - 2025-05-22 17:26 +0200
    Re: ssh keypairs vs. Passwort Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2025-05-21 23:00 +0200

#638591 — ssh keypairs vs. Passwort

Hallo,

ich habe ssh mit keypairs zumindest im LAN immer für eine unnötige
Sicherheitslücke gehalten - weil man nur Zugriff auf einen Rechner braucht und
dann überall hinkommt. Nein, ich glaube nicht, dass ich Angst haben muss, aber
ich muss ja auch nicht wider meinen Verstand oder mein Herz arbeiten.

An diejenigen von Euch, die als Admin arbeiten - wie sind da die best
practices? Am besten für den Key noch ein Passwort?
Sorgen unbegründet? Dass man auf öffentlich erreichbaren Rechner die
Authentifizierungsmethode password für ssh am besten abschaltet habe ich schon
verstanden als ich mir die Logs und so ein paar Minuten Traffic angeguckt
habe.

-- 
mit freundlichen Grüßen/with kind regards,

Christian Dürrhauer

[toc] | [next] | [standalone]

#638592

Christian Dürrhauer schrieb:

> ich habe ssh mit keypairs zumindest im LAN immer für eine unnötige
> Sicherheitslücke gehalten - weil man nur Zugriff auf einen Rechner braucht und
> dann überall hinkommt.

Das verstehe ich nicht.

> An diejenigen von Euch, die als Admin arbeiten - wie sind da die best
> practices? Am besten für den Key noch ein Passwort?

Ja, natürlich. Mindestens. - Wem das nicht ausreichend ist, der nutzt ein
Hardware Security Token (Yubikey o.ä.), so dass zusätzlich zur
Passworteingabe noch ein Token in einem USB-Port und dessen physische
Berührung erforderlich ist; sinnvoll insbesondere, wenn man
Agent-Forwarding nutzt oder Key/Passphrase für eine gewisse Zeit cached.

-thh

[toc] | [prev] | [next] | [standalone]

#638598

On May 21, 2025 at 10:58:44 PM GMT+2, "Thomas Hochstein" <thh@thh.name> wrote:

> Das verstehe ich nicht.

sorry, war etwas pauschal. Gemeint war: es reicht der Zugriff auf den einen
Rechner, auf dem ein Zugriff auf andere ssh-Server mittels
keypari-Authentifizierung eingerichtet ist, um auf all jene ssh-Server
zugreifen zu können. Man kann somit ohne weitere Hürde von System zu System
springen.

-- 
mit freundlichen Grüßen/with kind regards,

Christian Dürrhauer

[toc] | [prev] | [next] | [standalone]

#638610

Christian Dürrhauer schrieb:

> Gemeint war: es reicht der Zugriff auf den einen
> Rechner, auf dem ein Zugriff auf andere ssh-Server mittels
> keypari-Authentifizierung eingerichtet ist, um auf all jene ssh-Server
> zugreifen zu können.

Aber doch nur, wenn der Key keine Passphrase hat (das wäre bei
passwortbasierter Anmeldung identisch damit, das Passwort im Client zu
sperichern - beides macht man aus guten Gründen nicht), oder ggf. noch,
wenn Key/Passphrase während der Laufzeit eines Programms oder für einen
bestimmten Zeitraum gecached werden (was man üblicherweise unterbindet,
wenn man den Rechner in unsicherer Umgebung in Betrieb hinterlässt). Ich
sehe da keinen Unterschied zwischen passwort- und key-basierter Anmeldung.
Letztere ist grundsätzlich sicherer, weil man den Key _und_ die Passphrase
benötigt (und noch sicherer, wenn man ein Hardware Token verwendet, das
eine Bedienhandlung erfordert, aber das ist für den (semi-)privaten
Bereich m.E. Overkill - andererseits kann man ja auch paranoid sein und
trotzdem verfolgt werden).

-thh

[toc] | [prev] | [next] | [standalone]

#638658

On May 22, 2025 at 8:27:04 AM GMT+2, "Thomas Hochstein" <thh@thh.name> wrote:

> Christian Dürrhauer schrieb:
>
>> Gemeint war: es reicht der Zugriff auf den einen
>> Rechner, auf dem ein Zugriff auf andere ssh-Server mittels
>> keypari-Authentifizierung eingerichtet ist, um auf all jene ssh-Server
>> zugreifen zu können.
>
> Aber doch nur, wenn der Key keine Passphrase hat (das wäre bei
> passwortbasierter Anmeldung identisch damit, das Passwort im Client zu
> sperichern - beides macht man aus guten Gründen nicht), oder ggf. noch,
> wenn Key/Passphrase während der Laufzeit eines Programms oder für einen
> bestimmten Zeitraum gecached werden (was man üblicherweise unterbindet,
> wenn man den Rechner in unsicherer Umgebung in Betrieb hinterlässt). Ich
> sehe da keinen Unterschied zwischen passwort- und key-basierter Anmeldung.
> Letztere ist grundsätzlich sicherer, weil man den Key _und_ die Passphrase
> benötigt (und noch sicherer, wenn man ein Hardware Token verwendet, das
> eine Bedienhandlung erfordert, aber das ist für den (semi-)privaten
> Bereich m.E. Overkill - andererseits kann man ja auch paranoid sein und
> trotzdem verfolgt werden).
>
> -thh

:)

Full ACK.
Ich schau mal nach Keys mit Passwort. Ich hab's schon wo im Einsatz (nur halt
nicht bei NAS-Replikation) und bin da grundsätzlich mit zufrieden.

-- 
mit freundlichen Grüßen/with kind regards,

Christian Dürrhauer

[toc] | [prev] | [next] | [standalone]

#638593

On 5/21/25 21:32, Christian Dürrhauer wrote:
> Hallo,
> 
> ich habe ssh mit keypairs zumindest im LAN immer für eine unnötige
> Sicherheitslücke gehalten - weil man nur Zugriff auf einen Rechner braucht und
> dann überall hinkommt. Nein, ich glaube nicht, dass ich Angst haben muss, aber
> ich muss ja auch nicht wider meinen Verstand oder mein Herz arbeiten.

Wenn man Automatisierung zwischen Rechnern implementieren will geht es 
nicht wirklich anders. Ja, man kann mit 'sshpass' arbeiten, aber dann 
hat man das Password irgendwo im Klartext.

  Gerrit

[toc] | [prev] | [standalone]

Back to top | Article view | ger.ct

csiph-web