Skip to content

SSH Login ohne Passwort

Angeheftet Linux
  • Wird Zeit das man den Artikel hier mal vernünftig macht, habe deswegen gestern drei Stunden verplempert, weil vermutlich wg. der Hitze, der Groschen nicht fallen wollte 🙂

    Server

    Installation des Dienstes

    apt install openssh-server
    

    In der Datei /etc/ssh/sshd_config wird der SSH-Dienst gesteuert. Die Zeile, die uns interessiert.

    PermitRootLogin without-password
    

    Was bedeutet das jetzt?

    • without-password Der Passwort-Login für Root ist deaktiviert, dann kann man sich nur mittels SSH-Key einloggen, wenn dieser hinterlegt wurde.

    PermitRootLogin
    Specifies whether root can log in using ssh(1). The argument must be “yes”,
    “without-password”, “forced-commands-only”, or “no”. The default is “yes”.

    If this option is set to “without-password”, password authentication is disabled for
    root.

    If this option is set to “forced-commands-only”, root login with public key
    authentication will be allowed, but only if the command option has been specified
    (which may be useful for taking remote backups even if root login is normally not
    allowed). All other authentication methods are disabled for root.

    If this option is set to “no”, root is not allowed to log in.

    Quelle: http://manpages.ubuntu.com/manpages/trusty/en/man5/sshd_config.5.html

    Datei bearbeiten und dann den Dienst einmal neustarten

    service sshd restart
    

    oder

     /etc/init.d/ssh restart
    

    Client

    Wir erzeugen einen Key mit

    RSA (veraltet)

    ssh-keygen -t rsa -b 4096
    

    ED25519

    ssh-keygen -t ed25519
    

    Dann kopieren wir diesen Key auf das Zielsystem. Das geht aber nur, wenn

    PermitRootLogin yes
    

    steht. Also vorher auf dem Server umstellen und den Dienst neu starten!

    Key kopieren

    RSA (veraltet)

    cat .ssh/id_rsa.pub | ssh username@domain.com 'cat >> .ssh/authorized_keys'
    

    ED25519

    cat .ssh/id_ed25519.pub | ssh username@domain.com 'cat >> .ssh/authorized_keys'
    

    Fertig!

    Danach auf dem Server wieder auf

    PermitRootLogin without-password
    

    umstellen. Ganz wichtig!!

  • Wenn das mal nicht geht, ist der Ordner .ssh auf dem Ziel/Quelle nicht vorhanden.

    Dann auf dem Ziel/Quelle

    ssh-keygen -t rsa
    

    ausführen, danach geht es.

  • Ich habe heute den Ursprungsbeitrag mal vernünftig aktualisiert, weil ich gestern drei Stunden bei dem Testen von sshfs verplempert habe. Zu sshfs kommt auch noch ein Beitrag 😉

  • Wie ihr ja wisst, benutze ich das Forum hier auch gerne als Notizbuch 🙂 Also mal wieder was hier notieren. Mein Windows Systemadmin sagte mir heute, das es auch folgendes gibt

    # ssh-keygen -t ed25519
    Generating public/private ed25519 key pair.
    Enter file in which to save the key (/root/.ssh/id_ed25519): /tmp/ed
    Enter passphrase (empty for no passphrase): 
    Enter same passphrase again: 
    Your identification has been saved in /tmp/ed
    Your public key has been saved in /tmp/ed.pub
    The key fingerprint is:
    SHA256:D33HCTW7Dy0p5kQdFTkPudx1PQh0EHFgkBvxy8KwhGM root@frank-ms7c92
    The key's randomart image is:
    +--[ED25519 256]--+
    |         o=O*o=+=|
    |      .  oo o+oB+|
    |     E o  o.o.o+*|
    |    . o +o...oo=o|
    |       .So.o= O .|
    |         o.= o + |
    |          . .   .|
    |                 |
    |                 |
    +----[SHA256]-----+
    

    Der Key liegt nur in /tmp kopieren lohnt also nicht 🙂

    Ob das jetzt die Zukunft ist, kann ich nicht beantworten. Ich wollte es aber hier mal festhalten, weil es wohl mittlerweile auch von vielen Projekten benutzt wird.

  • FrankMF FrankM hat am auf dieses Thema verwiesen

  • Manjaro Stable jetzt mit Plasma 6

    Linux
    1
    0 Stimmen
    1 Beiträge
    209 Aufrufe
    Niemand hat geantwortet
  • Ansible - Proxmox Server bearbeiten

    Ansible
    1
    0 Stimmen
    1 Beiträge
    367 Aufrufe
    Niemand hat geantwortet
  • HSTS - Sicherheitsmechanismus für HTTPS-Verbindungen

    Linux
    1
    0 Stimmen
    1 Beiträge
    67 Aufrufe
    Niemand hat geantwortet
  • Star64 lieferbar

    Star64
    1
    0 Stimmen
    1 Beiträge
    66 Aufrufe
    Niemand hat geantwortet
  • 10G

    Linux
    2
    0 Stimmen
    2 Beiträge
    138 Aufrufe
    FrankMF

    Bedingt durch ein paar Probleme mit der Forensoftware, habe ich einen kleinen Datenverlust erlitten. Dazu gehören auch hier einige Beiträge. Dann versuche ich das mal zu rekonstruieren.

    Oben hatten wir das SFP+ Modul ja getestet. Als nächsten Schritt habe ich die ASUS XG-C100F 10G SFP+ Netzwerkkarte in meinen Hauptrechner verbaut.

    20211028_162455_ergebnis.jpg

    Die Verbindung zum Zyxel Switch erfolgt mit einem DAC-Kabel. Im Video zum Zyxel Switch wurde schön erklärt, das die DAC Verbindung stromsparender als RJ45 Adapter sind. Somit fiel die Wahl auf die DAC Verbindungen. Hier nochmal das Video.

    So sieht so ein DAC Verbindungskabel aus. Die SFP+ Adapter sind direkt daran montiert.

    20211028_170118_ergebnis.jpg

    ethtool root@frank-MS-7C37:/home/frank# ethtool enp35s0 Settings for enp35s0: Supported ports: [ FIBRE ] Supported link modes: 100baseT/Full 1000baseT/Full 10000baseT/Full 2500baseT/Full 5000baseT/Full Supported pause frame use: Symmetric Receive-only Supports auto-negotiation: Yes Supported FEC modes: Not reported Advertised link modes: 100baseT/Full 1000baseT/Full 10000baseT/Full 2500baseT/Full 5000baseT/Full Advertised pause frame use: Symmetric Advertised auto-negotiation: Yes Advertised FEC modes: Not reported Speed: 10000Mb/s Duplex: Full Port: FIBRE PHYAD: 0 Transceiver: internal Auto-negotiation: on Supports Wake-on: pg Wake-on: g Current message level: 0x00000005 (5) drv link Link detected: yes iperf3 ----------------------------------------------------------- Server listening on 5201 ----------------------------------------------------------- Accepted connection from 192.168.3.207, port 44570 [ 5] local 192.168.3.213 port 5201 connected to 192.168.3.207 port 44572 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 1.10 GBytes 9.43 Gbits/sec 46 1.59 MBytes [ 5] 1.00-2.00 sec 1.10 GBytes 9.42 Gbits/sec 0 1.60 MBytes [ 5] 2.00-3.00 sec 1.10 GBytes 9.42 Gbits/sec 3 1.60 MBytes [ 5] 3.00-4.00 sec 1.10 GBytes 9.42 Gbits/sec 0 1.60 MBytes [ 5] 4.00-5.00 sec 1.10 GBytes 9.42 Gbits/sec 0 1.61 MBytes [ 5] 5.00-6.00 sec 1.10 GBytes 9.42 Gbits/sec 0 1.63 MBytes [ 5] 6.00-7.00 sec 1.10 GBytes 9.42 Gbits/sec 0 1.63 MBytes [ 5] 7.00-8.00 sec 1.09 GBytes 9.41 Gbits/sec 0 1.68 MBytes [ 5] 8.00-9.00 sec 1.10 GBytes 9.42 Gbits/sec 0 1.68 MBytes [ 5] 9.00-10.00 sec 1.10 GBytes 9.42 Gbits/sec 0 1.68 MBytes [ 5] 10.00-10.02 sec 22.5 MBytes 9.45 Gbits/sec 0 1.68 MBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.02 sec 11.0 GBytes 9.42 Gbits/sec 49 sender
  • 2,5G

    Linux
    2
    0 Stimmen
    2 Beiträge
    144 Aufrufe
    FrankMF

    Gutes Video zum Zyxel Switch, was ich vorher gar nicht kannte. Hätte meine Entscheidung aber auch nicht verändert.

  • Debian 11.1 released

    Linux
    1
    0 Stimmen
    1 Beiträge
    152 Aufrufe
    Niemand hat geantwortet
  • OpenWRT - Zonen

    Verschoben OpenWRT & Ubiquiti ER-X
    2
    0 Stimmen
    2 Beiträge
    462 Aufrufe
    FrankMF

    Es ist was heller geworden 🙂

    7b86e97c-31a5-44b6-809f-25d9d1c2ee4a-image.png

    Die besagte Forward Regel

    Zonen.png

    Diese Forward Regel zieht erst dann, wenn es mehrere Interfaces in einer Zone gibt. Aus der Doku

    INPUT rules for a zone describe what happens to traffic trying to reach the router itself through an interface in that zone. OUTPUT rules for a zone describe what happens to traffic originating from the router itself going through an interface in that zone. FORWARD rules for a zone describe what happens to traffic passing between different interfaces belonging in the same zone.

    Das heisst nun, das ein Forwarding zwischen zwei Zonen immer eine spezifische Regel unter Traffic Rules benötigt.

    Forwarding between zones always requires a specific rule.

    Somit ist ein Forwarding zwischen zwei Zonen in den Standard Einstellungen nicht erlaubt. Das kann ich hier auch so bestätigen. Das ist ja auch das was ich mit meiner "DMZ"-Zone erreichen möchte. Kein Zugriff auf LAN.

    Unter Zone ⇒ Forwardings kann man jetzt sehen, das das Forwarding von LAN in Richtung WAN und DMZ erlaubt ist. WAN ist logisch, sonst komme ich ja nicht ins Internet. DMZ habe ich eingestellt, damit ich auch Teilnehmer im DMZ Netz erreichen kann, wenn ich da mal ran muss.

    8a548c29-8bc5-4074-8099-66460bcea9a8-image.png

    Stelle ich das jetzt so ein.

    dca8b393-f613-4cab-a377-ffbc2bb8ddf5-image.png

    Dann kann ich von der DMZ Zone aus das LAN erreichen. Aha, so langsam verstehe ich 😉

    Quelle: https://forum.openwrt.org/t/firewall-zones-and-settings/84369