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.
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.
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
Display MoreHallo 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.
Ich spiele gerade mit dem Gedanken, ein paar meiner Server innerhalb „meines Verbunds“ einzuschließen, also jeglichen Zugriff zu verbieten, mit Ausnahme von den „eigenen“ IPs. Das macht für mich vor allem für das Monitoring sowie meinen Docker Sinn.
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?
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.
#!/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
Display More