verbindung per putty mit ubuntu 14.04 per ssh nicht möglich

S

Snycs

Gast
Ich habe folgendes Problem: Wenn ich aus einem anderen Netzwerk auf meinen Server via SSH mit Putty zugreifen will bekomme ich die meldung Acces Denied. (Sprich ich gebe meinen Username und mein Passwort ein und dann kommt die meldung)

Die Ports sind freigegeben und anpingen kann ich ihn auch. Im Lan gibts keine Probleme. Als DynDNS Anbieter habe ich Selfhost. Ich hoffe mir kann jemand helfen, da ich den server so schnell wie möglich zum laufen bringen muss.

Mit freundlichen Grüßen
EliteHD
 
log lesen
firewall und accessregeln beachten

/edit: bitte anderes entzwerk genauer definieren

Netzwerk A =?
Netzwerk B =?

/edit2: SSH by RSA FTW
 
Zuletzt bearbeitet:
ports sind sowohl in der firewall als auch um router und im swich freigegeben

Server = (192.168.0.4)
NW A = Lan (192.168.0.2)
NW B = Internet (zb. 89.37.87.3)

Mit freundlichen grüßen
EliteHD
 
firewall installiert?
ufw, fail2ban etc

zugriff nur aus dem LAN erlaubt?
accessregeln

sperregeln/firewall die SSH aus dem internet generell blockiert?
regeln die den zugriff aus einem bestimmten IP-bereich blockiert?

nmap auf deine IP zeigt das port 22 offen ist?

der SSH user darf von extern überhaupt zugreifen?


ps -A | grep sshd

sudo ss -lnp | grep sshd

service ssh restart

/etc/ssh/ssh_config
/etc/ssh/sshd_config

/var/log/auth.log
 
Jo, klingt danach als wenn SSH grundsätzlich nur auf Zugriffe aus dem eigenen LAN reagiert.

In obiger Konfig (/etc/ssh/ssh_config) gibt es einen Eintrag "Hosts". Dort sind die zulässigen Quell-IP(-Ranges) definiert.

Darüberhinaus kann es natürlich auch sein, dass die Firewall grundsätzlich alles blockt, das von einer fremden IP kommt.



Portweiterleitung ---> Firewall ---> ssh_config
 
"Access denied" klingt doch ganz klar nach einer Rückmeldung vom sshd, insofern kann die Firewall da eigentlich keine Probleme machen.
 
Stimmt, da hast du auch wieder Recht ;)
 
Wenn der Port nicht weitergeleitet oder der Zugriff auf Port22 aus dem WWW nicht erlaubt wäre, käme man gar nicht erst zum Eingeben von User/PW. Das wäre dann meist ein "Connection timed out".

poste mal deine sshd_config.
 
Hier ist die sshd_config

Code:
# Package generated configuration file
# See the sshd_config(5) manpage for details

# What ports, IPs and protocols we listen for
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 1024

# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:
LoginGraceTime 120
#PermitRootLogin without-password
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile	%h/.ssh/authorized_keys

# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes

# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Change to no to disable tunnelled clear text passwords
#PasswordAuthentication yes

# Kerberos options
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no

#MaxStartups 10:30:60
#Banner /etc/issue.net

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

Subsystem sftp /usr/lib/openssh/sftp-server

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes

MFG
EliteHD
 
Bestimmten Grund, dass du:
1. #PasswordAuthentication yes
auskommentiert hast?
2. UsePAM yes
auf yes geändert hast?
 
EliteHD schrieb:
wo bekomm ich die auth.log her?
Versteh mich bitte nicht falsch, aber bist du dir sicher, dass du ssh von außen erreichbar machen willst, wenn dir die Basiskenntnisse fehlen? Im Zweifelsfalle baust du gerade das nächste Mitglied im Botnetz von Hackergruppe xy, weil dein Passwort nicht stark genug war...

1.) Nimm unbedingt ein kompliziertes Passwort. Groß- und Kleinbuchstaben, Sonderzeichen, Zahlen. Nicht aufeinanderfolgend und möglichst lang. Merk dir zB einen Satz wie "Bei computerbase.de lese ich jeden Tag 7 Threads" und nimm jeweils die Anfangsbuchstaben => Bc.delijT7T
2.) Ändere den SSH-Port von 22 auf einen anderen (zb 25379)
3.) Wenn möglich, lass SSH zB nur lokal aus dem LAN oder über ein VPN zu
4.) Nutze Skripte wie fail2ban o.ä., die nach x falschen Loginversuchen die IP für y Minuten/Stunden/Tage sperren.


Punkt 2 ist streng genommen kein Sicherheitsfeature, eher eine Verschleierungstaktik. "Security by obscurity" nennt sich das. Wenn der Einbrecher die Tür gar nicht erst findet, kann er das Schloss auch nicht knacken. Die Portscans, die Hacker permanent laufen haben, klappern in der Regel nur die gängigsten Ports ab. In den Logs sieht man nämlich wie man zT bombardiert wird mit Loginversuchen auf Port 22. Daher auch Punkt 4, der Wörterbuchattacken ziemlich schnell ins Leere laufen lässt. Nach dem 3. falschen Login war's das. Allerdings sollte man das nicht zu scharf einstellen, weil man sich genauso schnell selbst aussperren kann (zB CapsLock).
 
Das Passwort hat 32 zeichen darunter Sonderzeichen, Großbuchstaben, kleinbuchstaben und zahlen. also das ist nicht sie schwachstelle^^
wie kann ich ssh so konfigurieren dass ich nur über einen vpn reinkomme? und wie kann ich dann mit meinem client darauf zugreifen?
Das plugin werde ich gleich mal installieren. danke für den tipp.

Zugreifen kann ich aus irgendeinem grund. ich weiss nicht warum aber es funktioniert.

MFG
EliteHD
 
Zuletzt bearbeitet von einem Moderator:
Muss mich wohl Rajin anschließen. Dass man gerade nicht weiß, wo die auth.log liegt kann schon passieren, aber du scheinst tatsächlich kaum Ahnung von irgendwas zu haben.
Bitte, bitte mach deinen Server nicht im Internet verfügbar, ohne dich vorher weiter einzuarbeiten. Rajin hat schon gute Tips gegeben, aber auch das schützt dich nicht vor Angreifern.
Dein Server ist schneller übernommen als du glaubst. Wenn der Angreifer deinen Server dann für Angriffe auf andere nutzt bist du haftbar - und das kann verdammt teuer werden.
Das ist kein Spaß, ist einem Bekannten passiert. Bitte lass es wenigstens vorerst bleiben.
 
wenn das risiko so hoch ist dann werde ich den ssh zugang nur fürs lan freigeben. welche einstellungen muss ich da denn in der config ändern?

MFG
ElliteHD
 
Zurück
Oben