So musst du dir kein Passwort merken
Außer du verschlüsselst den SSH Key mit einem Passwort. 
Dennoch bin ich auch der Meinung, dass ein SSH Key weiterhin sinnvoll ist. Vielleicht dann aber ohne die vorher angemerkte Verschlüsselung. 
Server administrieren - wo fange ich an?
-
Bud -
April 30, 2023 at 1:48 PM -
Thread is Resolved
-
-
Für manche Sever nutze ich keine keys. Und zwar für die, auf die von allen möglichen verschiedenen Rechnern aus zugegriffen werden muss und das auch noch von mehr als einem Admin. Langes, aber leicht zu merkendes Passwort und gut ist.
-
Wenn ich einen Zugriff auf all meine Server via SSH nur für eine IP erlaube (VPN Server), bringt mir ein SSH-Key dann noch irgendeinen Vorteil, oder kann ich mir das sorgenfrei sparen?
IMHO ist Sicherheit etwas, dass aus vielen verschiedenen großen und kleinen Dingen zusammengesetzt ist, die alle zum Ziel haben, verschiedene Risiken zu minimieren. Wenn man jetzt anfängt, einzelne Dinge wegzulassen, weil andere „bessere“ Dinge sie vermeintlich überflüssig machen, verschenkt man Securitypotential. Ich tippe lieber einmal das Passwort für mein Keyfile.
-
durch den unverschlüsselten key gewinne ich ja bequemlichkeit.
soetwas würde ich niemals weglassen und auf meinen ssh-servern ist eh' nur key-login erlaubt.
-
Ist meiner Meinung nach immer eine Abwägung zwischen Bequemlichkeit und Sicherheit.
Ich verwende grundsätzlich nur Keys mit Passwort, dann muss ich mir weniger Gedanken machen, ob ein Server nur via Hop oder evtl. doch direkt erreichbar ist.
Passworte sind eher die Ausnahme, z.b. bei Test-Systemen oder für unprivilegierte User (ohne sudo etc.)
Allerdings muss ich zugeben, dass ich mit passwortgeschützten Keys gerade bei automatisierten Aufgaben (Ansible, cron, ...) so meine Probleme habe.
-
Allerdings muss ich zugeben, dass ich mit passwortgeschützten Keys gerade bei automatisierten Aufgaben (Ansible, cron, ...) so meine Probleme habe.
Ich würde dir raten, nicht den Key selbst zu verschlüsseln sondern lieber den Private Key in einem Passwort Manager zu hinterlegen. Viele Passwort Manager z.B. 1password haben einen SSH-Agent mit an Board. So hat man jederzeit den Private Key an einem sicheren Ort, gleichzeitig kann man sich ganz bequem zu den Servern verbinden. Auch bieten viele Passwort Manager CLI Tools an, um eben Automatisierungen zu ermöglichen.
-
Meine SSH-Server sind nur über ein VPN erreichbar. Zusätzlich habe ich noch einen Jump-Host.
Ich verwende ausschließlich SSH-Keys mit Passwort. Die speichere ich in meinem User-Keyring.
Ansible nutzt den Keyring, so dass ich problemlos automatisieren kann, trotz Password.
-
Hallo zusammen,
ich habe bei einem meiner Server angefangen bei Neuinstallationen nicht mehr den Apache2 zu verwenden, sondern nginx.
Des Weiteren zeigt es mir die eine Apache2 Startseite ein und nicht die von nginx.
Dabei ist apache2 gar nicht installiert.
Installiert ist certbot letsencrypt php8.3 sury
-
Hallo zusammen,
ich habe bei einem meiner Server angefangen bei Neuinstallationen nicht mehr den Apache2 zu verwenden, sondern nginx.
Des Weiteren zeigt es mir die eine Apache2 Startseite ein und nicht die von nginx.
Dabei ist apache2 gar nicht installiert.
Installiert ist certbot letsencrypt php8.3 sury
Hat sich erledigt.
Das Problem saß vor dem Computer.
-
Das kommt darauf an wie scharf du das Ganze betreiben willst, zumal (zumindest ich) deine Systeme und deren Kommunikationsbeziehungen nicht kenne^^
Also zunächst rein generisch:
Ein Anfang wäre es, der/die Firewall(s) auf "DENY incoming" zu setzen (keine eingehenden Verbindungen erlaubt). Per Whistelisting dann die eigenen IPs + nötige Ports,etc. erlauben.
Im Ergebnis lässt dein Server nun keine eingehenden Kommunikationsbezeihungen außer von den erlaubten IPs und zu den konfigurierten Ports zu.
Ausgehend kann man das Ganze natürlich auch beliebig komplex konfigurieren, aber ein "ALLOW outgoing" (ausgehende Verbindungen vom Server sind erlaubt) sollte ahS erstmal absolut OK sein.
Im Gesamtergebnis können nur noch deine eigenen IPs über von dir definierte Ports mit dem Server sprechen. Ausgehend würden hier zunächst keine Einschränkungen herrschen, womit auch ein "apt update",etc. weiterhin as usual funktioniert.
Wenn dein "apt update" eine Verbindung zu bspw. den Debian-Repo-Servern aufbaut, ist die anschließende und zugehörige eingehende Verbindung zulässig. Hier muss also nichts zusätzlich bei eingehenden Verbindungen konfiguriert werden.
Das ist jetzt aber (wie genannt) absolut generisch ohne Round-About...würde aber so funktionieren.
-----------------------
Ich betreibe bspw. diverse Services in einem "Backend". D.h. hier befinden sich mehrere Services innerhalb eines privaten IPv4-Netzes und einem zusätzlichen IPv6-Subnetz (ich nutze Proxmox, daher das zusätzliche Subnetz...sonst ist das bei Netcup mit IPv6 leider nur ein rumgesch*sse)
Als "Gatekeeper" terminieren alle eingehenden Verbindungen immer auf einem vorgeschalteten Reverse-Proxy (nginx), der das Ganze dann in mein "Backend" zum entsprechenden Service weiterschubst. Meine Services selber lassen Ausnahmslos nur eingehenden IP-Verkehr aus diesem genannten, privaten IPv4-Netz sowie nur meinem eigenem zusätzlichen IPv6-Subnetz zu. D.h. von "außen" kommt keiner an die Services.
Auch alle meine DNS-Records terminieren alle auf dem Reverse-Proxy.
Bildlich gesehen eine "Bubble" mit allen meinen Services und einem Reverse-Proxy obendrauf. Intern können die miteinander sprechen wie sie wollen...von außen geht`s nur über den Revers-Proxy rein.
Das Ganze könnte man eingehend am Reverse-Proxy jetzt natürlich (wie in deiner Idee) noch auf bestimmte IPs festnageln..
Da gibt es auch andere Lösungen, aber in meinem Fall war das für mich die zweckmäßigste.
-
Spricht da etwas dagegen? Wie stelle ich sicher, dass z. B. unattended-upgrades oder natürlich auch ein manuelles apt update etc. nach wie vor funktioniert? Wie kann ich den Servern erlauben, weiterhin Nachrichten via TelegramBot zu versenden?
Port 80 und 443 TCP und 53 UDP ausgehend erlauben. Damit funktionieren APT, Telegram Bot und DNS noch sauber.
Bash
Display More#!/bin/sh #IPv4 Firewall iptables -F iptables -P INPUT ACCEPT iptables -P OUTPUT ACCEPT iptables -P FORWARD ACCEPT iptables -A INPUT -i lo -j ACCEPT iptables -A OUTPUT -o lo -j ACCEPT iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A INPUT -p 41 -j DROP iptables -A FORWARD -p 41 -j DROP #Updateserver iptables -A OUTPUT -p tcp -m tcp --dport 80 -m state --state NEW -j ACCEPT iptables -A OUTPUT -p tcp -m tcp --dport 443 -m state --state NEW -j ACCEPT #DNS iptables -N CH-DNS iptables -A OUTPUT -p tcp -m tcp --dport 53 -m state --state NEW -j CH-DNS iptables -A OUTPUT -p udp -m udp --dport 53 -m state --state NEW -j CH-DNS iptables -A CH-DNS -d 8.8.4.4 -j ACCEPT iptables -A CH-DNS -d 8.8.8.8 -j ACCEPT #ICMP iptables -A INPUT -p icmp -m icmp --icmp-type any -m state --state NEW -j ACCEPT iptables -A OUTPUT -p icmp -m icmp -o eth0 --icmp-type any -m state --state NEW -j ACCEPT #Global Policy Reject iptables -A INPUT -j REJECT iptables -A FORWARD -j REJECT iptables -A OUTPUT -j REJECT #IPv6 Firewall ip6tables -F ip6tables -P INPUT ACCEPT ip6tables -P OUTPUT ACCEPT ip6tables -P FORWARD ACCEPT ip6tables -A INPUT -i lo -j ACCEPT ip6tables -A OUTPUT -o lo -j ACCEPT ip6tables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT ip6tables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT ip6tables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT ip6tables -A INPUT -s fe80::/10 -j ACCEPT ip6tables -A OUTPUT -s fe80::/10 -j ACCEPT #DNS ip6tables -N CH-DNS ip6tables -A OUTPUT -p tcp -m tcp -o eth0 --dport 53 -m state --state NEW -j CH-DNS ip6tables -A OUTPUT -p udp -m udp -o eth0 --dport 53 -m state --state NEW -j CH-DNS ip6tables -A CH-DNS -d 2001:4860:4860::8888 -j ACCEPT ip6tables -A CH-DNS -d 2001:4860:4860::8844 -j ACCEPT #ICMP ip6tables -N CH-ICMP-IN ip6tables -N CH-ICMP-FW ip6tables -A INPUT -p icmpv6 -j CH-ICMP-IN ip6tables -A INPUT -p icmpv6 -j CH-ICMP-FW ip6tables -A FORWARD -p icmpv6 -j CH-ICMP-FW ip6tables -A OUTPUT -p icmpv6 -j CH-ICMP-IN ip6tables -A OUTPUT -p icmpv6 -j CH-ICMP-FW #ICMP Neighbor Discovery ip6tables -A CH-ICMP-IN -p icmpv6 --icmpv6-type 130 -j ACCEPT ip6tables -A CH-ICMP-IN -p icmpv6 --icmpv6-type 131 -j ACCEPT ip6tables -A CH-ICMP-IN -p icmpv6 --icmpv6-type 132 -j ACCEPT ip6tables -A CH-ICMP-IN -p icmpv6 --icmpv6-type 133 -j ACCEPT ip6tables -A CH-ICMP-IN -p icmpv6 --icmpv6-type 134 -j ACCEPT ip6tables -A CH-ICMP-IN -p icmpv6 --icmpv6-type 135 -j ACCEPT ip6tables -A CH-ICMP-IN -p icmpv6 --icmpv6-type 136 -j ACCEPT ip6tables -A CH-ICMP-IN -p icmpv6 --icmpv6-type 141 -j ACCEPT ip6tables -A CH-ICMP-IN -p icmpv6 --icmpv6-type 142 -j ACCEPT ip6tables -A CH-ICMP-IN -p icmpv6 --icmpv6-type 143 -j ACCEPT ip6tables -A CH-ICMP-IN -p icmpv6 --icmpv6-type 148 -j ACCEPT ip6tables -A CH-ICMP-IN -p icmpv6 --icmpv6-type 149 -j ACCEPT ip6tables -A CH-ICMP-IN -p icmpv6 --icmpv6-type 151 -j ACCEPT ip6tables -A CH-ICMP-IN -p icmpv6 --icmpv6-type 152 -j ACCEPT ip6tables -A CH-ICMP-IN -p icmpv6 --icmpv6-type 153 -j ACCEPT ip6tables -A CH-ICMP-FW -m state --state INVALID -j DROP ip6tables -A CH-ICMP-FW -m state --state ESTABLISHED -j ACCEPT ip6tables -A CH-ICMP-FW -p icmpv6 --icmpv6-type 1 -m state --state RELATED -j ACCEPT ip6tables -A CH-ICMP-FW -p icmpv6 --icmpv6-type 2 -m state --state RELATED -j ACCEPT ip6tables -A CH-ICMP-FW -p icmpv6 --icmpv6-type 3 -m state --state RELATED -j ACCEPT ip6tables -A CH-ICMP-FW -p icmpv6 --icmpv6-type 4 -m state --state RELATED -j ACCEPT ip6tables -A CH-ICMP-FW -p icmpv6 --icmpv6-type 128 -m state --state NEW -j ACCEPT #Global Policy Reject ip6tables -A INPUT -j REJECT ip6tables -A FORWARD -j REJECT ip6tables -A OUTPUT -j REJECT -
Hast du denn mal versucht dich mit einem deiner anderen Server zu verbinden, bei denen su weißt, dass es geht, statt bei diesem neu installierten?
Nur um zu testen, ob es nicht etwa am neuen Client liegt, sondern am neuen Server.
-
Code
Display Moredebug1: Will attempt key: /home/bud/.ssh/id_rsa debug1: Will attempt key: /home/bud/.ssh/id_ecdsa debug1: Will attempt key: /home/bud/.ssh/id_ecdsa_sk debug1: Will attempt key: /home/bud/.ssh/id_ed25519 debug1: Will attempt key: /home/bud/.ssh/id_ed25519_sk debug1: Will attempt key: /home/bud/.ssh/id_xmss debug1: Will attempt key: /home/bud/.ssh/id_dsa debug1: Trying private key: /home/bud/.ssh/id_rsa debug3: no such identity: /home/bud/.ssh/id_rsa: No such file or directory debug1: Trying private key: /home/bud/.ssh/id_ecdsa debug3: no such identity: /home/bud/.ssh/id_ecdsa: No such file or directory debug1: Trying private key: /home/bud/.ssh/id_ecdsa_sk debug3: no such identity: /home/bud/.ssh/id_ecdsa_sk: No such file or directory debug1: Trying private key: /home/bud/.ssh/id_ed25519 debug3: no such identity: /home/bud/.ssh/id_ed25519: No such file or directory debug1: Trying private key: /home/bud/.ssh/id_ed25519_sk debug3: no such identity: /home/bud/.ssh/id_ed25519_sk: No such file or directory debug1: Trying private key: /home/bud/.ssh/id_xmss debug3: no such identity: /home/bud/.ssh/id_xmss: No such file or directory debug1: Trying private key: /home/bud/.ssh/id_dsa debug3: no such identity: /home/bud/.ssh/id_dsa: No such file or directoryWo liegt denn die Key-Datei und wie heißt sie? Gib sie mal mit -i explizit an.
-
-
Hast du den Key als anderer user / root erzeugt oder dem einen anderen Namen gegeben? Das ist der, der nach deinem ssh-keygen funktionieren müsste:
Codeno such identity: /home/bud/.ssh/id_ed25519: No such file or directoryGibt's den?
-
Wo liegt denn die Key-Datei und wie heißt sie? Gib sie mal mit -i explizit an.
Danke, ich hatte ganz vergessen die config mitzuposten:
CodeHost bud.example.com HostName 192.0.2.211 User bud PubKeyAuthentication yes IdentityFile key/private.txtWenn ich den Schlüssel, wie von dir vorgeschlagen, direkt mit angebe, funktioniert es: ssh -i /home/bud/.ssh/key/private.txt bud@192.0.2.211
Daraufhin dachte ich, dass ich vielleicht den gesamten Pfad in der config mit angeben muss, was aber die gleiche Fehlermeldung erzeugt.Und keinen Nutzer, der sich mit Passwort einloggen kann?
Auf meinen Servern? Nein.
