[SSH] Inloggen van buitenaf niet toegestaan?

[Peedy]

Hey,

Ik draai SSH op mijn SuSE bak... als ik vanaf mijn PC (intern netwerk) inlog op SSH, werkt alles perfect. Maar als iemand anders het via internet probeert, dan geeft hij steeds Access Denied.

login as: root
Sent username "root"
[e-mail]'s password:
Access denied

Ook met username/password combinatie van mijn normale user werkt het niet..
Ik heb gekeken in /etc/ssh/sshd-config en /etc/hosts.allowed en /etc/hosts.denied maar hier kan ik niets bijzonders vinden... wie weet raad?

[ Voor 3% gewijzigd door Peedy op 16-10-2005 15:54 ]

[Erkens]

En als je het doet met een normaal account?

[Peedy]

Al geprobeerd..

Ook met username/password combinatie van mijn normale user werkt het niet..

[ Voor 25% gewijzigd door Peedy op 16-10-2005 15:41 ]

[MrBarBarian]

begluur je logs eens

(waarom zie ik dat nooit iemand doen? Linux heeft zo'n prachtig en super uitgebreide logmogelijkheid))

[ Voor 35% gewijzigd door MrBarBarian op 16-10-2005 15:42 ]

[Peedy]

Ik ben behoorlijk nieuw met Linux...welke logs zou ik dan moeten bekijken?

[MrBarBarian]

syslog en authlog, beide in /var/log of /var/adm

En dat had je moeten vinden via google

[ Voor 32% gewijzigd door MrBarBarian op 16-10-2005 15:43 ]

[Peedy]

fileserver:~ # less /var/log/syslog
/var/log/syslog: No such file or directory
fileserver:~ # less /var/adm/syslog
/var/adm/syslog: No such file or directory
fileserver:~ # less /var/log/authlog
/var/log/authlog: No such file or directory
fileserver:~ # less /var/adm/authlog
/var/adm/authlog: No such file or directory

Helaas...

[GlowMouse]

Kijk dan eens onder /var/log of daar wel andere bruikbare logs staan.
En kijk ook in je sshd-configfile (meestal onder /etc) of daar bepaalde dingen instaan.

[Peedy]

GlowMouse schreef op zondag 16 oktober 2005 @ 15:53:
Kijk dan eens onder /var/log of daar wel andere bruikbare logs staan.
En kijk ook in je sshd-configfile (meestal onder /etc) of daar bepaalde dingen instaan.

Waarom leest niemand dit topic eventjes door??

Ik heb gekeken in /etc/ssh/sshd-config en /etc/hosts.allowed en /etc/hosts.denied maar hier kan ik niets bijzonders vinden... wie weet raad?

... in /var/log staat niet veel bijzonders m.b.t. SSH

[ Voor 7% gewijzigd door Peedy op 16-10-2005 15:57 ]

[Erkens]

pEeDy16 schreef op zondag 16 oktober 2005 @ 15:18:
Ik heb gekeken in /etc/ssh/sshd-config en /etc/hosts.allowed en /etc/hosts.denied maar hier kan ik niets bijzonders vinden... wie weet raad?

Wellicht handig om die config file eens met ons te delen dan dat wij allerlei dingen moeten gokken.
Daarnaast is het wellicht verstandig om wat tutorials etc door te lezen, want als je niet eens weet waar je log files zijn, hoe wil je dan een server veilig online gooien?

[MrBarBarian]

pEeDy16 schreef op zondag 16 oktober 2005 @ 15:54:
[...]

Waarom leest niemand dit topic eventjes door??

omdat jij geen google gebruikt.

[rdfeij]

Ik gok een port forwarding foutje.

Zorg dat in je router, poort 22 geforward wordt naar het ip van je Suse box.

[Erkens]

rdfeij schreef op zondag 16 oktober 2005 @ 15:59:
Ik gok een port forwarding foutje.

Zorg dat in je router, poort 22 geforward wordt naar het ip van je Suse box.

Dan had je niet eens verbinding gekregen als je firewall blocked

[Glaanie]

Op mijn FreeBSD bak had ik dezelfde problemen. Het bleek dat een root login standaard niet toegestaan is buiten het lokale netwerk. Er moest een config file veranderd worden, maar welke, ik heb geen idee meer, de FreeBSD bak is nu een jaar werkloos, wegens een mobo fout

[Peedy]

Erkens schreef op zondag 16 oktober 2005 @ 15:58:
[...]

Wellicht handig om die config file eens met ons te delen dan dat wij allerlei dingen moeten gokken.
Daarnaast is het wellicht verstandig om wat tutorials etc door te lezen, want als je niet eens weet waar je log files zijn, hoe wil je dan een server veilig online gooien?

code:

# $OpenBSD: sshd_config,v 1.69 2004/05/23 23:59:53 dtucker Exp $ # This is the sshd server system-wide configuration file. See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented. Uncommented options change a
# default value.

#Port 22
#Protocol 2,1
#ListenAddress 0.0.0.0
#ListenAddress ::

# HostKey for protocol version 1
#HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key

# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 1h
#ServerKeyBits 768

# Logging
#obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
#PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 6

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

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

# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication yes
#PermitEmptyPasswords no

# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes

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

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

# Set this to 'yes' to enable support for the deprecated 'gssapi' authentication
# mechanism to OpenSSH 3.8p1. The newer 'gssapi-with-mic' mechanism is included
# in this release. The use of 'gssapi' is deprecated due to the presence of 
# potential man-in-the-middle attacks, which 'gssapi-with-mic' is not susceptible to.
#GSSAPIEnableMITMAttack no


# 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 mechanism. 
# Depending on your PAM configuration, this may bypass the setting of 
# PasswordAuthentication, PermitEmptyPasswords, and 
# "PermitRootLogin without-password". If you just want the PAM account and 
# session checks to run without PAM authentication, then enable this but set 
# ChallengeResponseAuthentication=no
UsePAM yes

#AllowTcpForwarding yes
#GatewayPorts no
X11Forwarding yes 
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#UsePrivilegeSeparation yes
#PermitUserEnvironment no
#Compression yes
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS yes
#PidFile /var/run/sshd.pid
#MaxStartups 10

# no default banner path
#Banner /some/path

# override default of no subsystems
Subsystem sftp /usr/lib/ssh/sftp-server

# This enables accepting locale enviroment variables LC_* LANG, see sshd_config(5).
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES 
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT 
AcceptEnv LC_IDENTIFICATION LC_ALL
IgnoreRhosts yes
IgnoreUserKnownHosts no
PrintMotd yes
StrictModes yes
RSAAuthentication yes
PermitRootLogin yes
PermitEmptyPasswords no

Erkens schreef op zondag 16 oktober 2005 @ 16:00:
[...]

Dan had je niet eens verbinding gekregen als je firewall blocked

Inderdaad.. hij vind namelijk wel connectie maar hij auth niet..

Glaanieboy schreef op zondag 16 oktober 2005 @ 16:03:
Op mijn FreeBSD bak had ik dezelfde problemen. Het bleek dat een root login standaard niet toegestaan is buiten het lokale netwerk. Er moest een config file veranderd worden, maar welke, ik heb geen idee meer, de FreeBSD bak is nu een jaar werkloos, wegens een mobo fout

Maar permitrootlogins staat in sshd_config op 'yes' en met het normale account werkt het ook niet..dus dit ligt iets anders.

[ Voor 7% gewijzigd door Peedy op 16-10-2005 16:08 ]

[_JGC_]

Elke distro heeft zijn eigen logfile instellingen, dus /var/log/syslog hoeft niet per se te bestaan. Kijk eens met ls in /var/log welke bestanden er wel zijn en geef hier meer informatie uit.

[MrBarBarian]

_JGC_ schreef op zondag 16 oktober 2005 @ 16:31:
Elke distro heeft zijn eigen logfile instellingen, dus /var/log/syslog hoeft niet per se te bestaan. Kijk eens met ls in /var/log welke bestanden er wel zijn en geef hier meer informatie uit.

_{als syslog niet bestaat wordt er waarschijnlijk gebruik gemaakt van messages, maar dat kan TS ook zelf uitvinden}

[Erkens]

pEeDy16 schreef op zondag 16 oktober 2005 @ 16:07:

code:

# 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 mechanism. 
# Depending on your PAM configuration, this may bypass the setting of 
# PasswordAuthentication, PermitEmptyPasswords, and 
# "PermitRootLogin without-password". If you just want the PAM account and 
# session checks to run without PAM authentication, then enable this but set 
# ChallengeResponseAuthentication=no
UsePAM yes

Heeft het niet met die PAM meuk te maken?

[Verwijderd]

Alles met een # voor is commentaar, dus je moet

code:

#PermitRootLogin yes

"uncommenten",
net zoals je sshd op een bepaald adres moet luisteren om verbindingen van buitenaf toe te staan

code:

 #ListenAddress 0.0.0.0
#ListenAddress ::

uncomment de eerste van deze regels eens, en vergeet niet om sshd opnieuw op te starten.

Of het veilig is of niet om root toe te laten van buitenaf moet je zelf overwegen,
ik zou het in ieder geval niet doen.

[ Voor 3% gewijzigd door Verwijderd op 16-10-2005 16:48 . Reden: sluiperige schrijvfouten.. ]

[Soultaker]

Ik gok ook op een probleem met PAM.

Volgens de TS krijgt 'ie wél verbinding en de kans om zich te authenticeren, maar wordt 'ie geweigerd, óók met een niet-root account. Dat betekent dat de SSH daemon zelf prima bereikbaar is en het toestaan van root-logins niet aan de orde (en onverstandig natuurlijk).

[Peedy]

Verwijderd schreef op zondag 16 oktober 2005 @ 16:46:
Alles met een # voor is commentaar, dus je moet

code:

#PermitRootLogin yes

"uncommenten",
net zoals je sshd op een bepaald adres moet luisteren om verbindingen van buitenaf toe te staan

code:

 #ListenAddress 0.0.0.0
#ListenAddress ::

uncomment de eerste van deze regels eens, en vergeet niet om sshd opnieuw op te starten.

Of het veilig is of niet om root toe te laten van buitenaf moet je zelf overwegen,
ik zou het in ieder geval niet doen.

Het is alleen even tijdelijk Ik zal het nu even proberen.

Edit; nu werkt het inderdaad
Het was alleen even nodig om een vriend een eggdrop te laten instellen via SSH... als hij klaar is gooi ik het weer dicht

[ Voor 13% gewijzigd door Peedy op 16-10-2005 17:05 ]

[Polichism]

pEeDy16 schreef op zondag 16 oktober 2005 @ 15:49:
[...]

Helaas...

less /var/log/auth.log

[Guru Evi]

Verander gewoon:

#AllowTcpForwarding yes

in:

AllowTcpForwarding yes

-> Probleem opgelost

[Coen Rosdorff]

Guru Evi schreef op maandag 17 oktober 2005 @ 19:51:
Verander gewoon:

#AllowTcpForwarding yes

in:

AllowTcpForwarding yes

-> Probleem opgelost

Hoho, dit zet iets heel anders aan dan waar de TS problemen mee heeft. Ik heb de TS nergens iets zien zeggen over port-forwarding.

[Guru Evi]

Ik draai SSH op mijn SuSE bak... als ik vanaf mijn PC (intern netwerk) inlog op SSH, werkt alles perfect. Maar als iemand anders het via internet probeert

Simpel: TS heeft NAT firewall (waarschijnlijk routerke) en heeft poort 22 doorgemapt naar zijn server.

[Peedy]

Guru Evi schreef op dinsdag 18 oktober 2005 @ 13:15:
[...]


Simpel: TS heeft NAT firewall (waarschijnlijk routerke) en heeft poort 22 doorgemapt naar zijn server.

Maar zoals je ziet in mijn openingspost kan je wél connectie maken...alleen authoriseren lukte niet. Nu wel though..dus probleem is al opgelost

[Thc_Nbl]

Ik zou toch eens kijken wat er in de /etc/pam.d/ssh staat.
zoals andere ook al aangeven zit daar het probleem.

wat je kan doen omdat te takkelen.

zet UsePAM no in je config.

voor de veiligheid doe ik het volgende
addgroup -gid 299 sshaccessgroup
adduser yournaam sshaccessgroup

in de sshd_config
zet deze regel erbij.
AllowGroups sshaccessgroup
deze zorgt dat niet zomaar iedereen kan inloggen of proberen, het is maar een beetje
extra beveiliging, maar werkt wel.

controleer je /etc/hosts.allow
sshd: ALL kan je erin zetten om zeker te zijn dat je altijd kan inloggen.

herstart je ssh en probeer opnieuw

[Erkens]

Thc_Nbl schreef op dinsdag 18 oktober 2005 @ 14:17:
controleer je /etc/hosts.allow
sshd: ALL kan je erin zetten om zeker te zijn dat je altijd kan inloggen.

herstart je ssh en probeer opnieuw

voor alle settings die je noemt moet je idd sshd herstarten, behalve voor hosts.allow/hosts.deny, die kan je gewoon editen en het werkt direct.