Debian: Mag niet remote inloggen?

[BHQ]

Situatie: Debian Sarge (stable) server met als enig pakket DirectAdmin en de APF firewall.

Ivm veiligheid maakte ik dus 2 normale user-accounts aan om daarop de server te beheren ipv. continu op root te werken. Het probleem is dat ik enkel met root remote in mag loggen, ik krijg de error 'access denied' als ik erheen SSH en inlog met de pasgemaakte accounts.

Hoe kan ik dit rechtzetten?

[Keeper of the Keys]

Kun je de inhoud van je /etc/ssh/sshd_config file posten?

[Whollabilla]

ik denk dat je moet instellen welke tty's veilig worden gevonden door jou, ik zal nog ff opzoeken hoe het precies gaat, maar ik weet dat ik het ook had toen ik Gentoo uitprobeerde (alleen kon ik toen niet lokaal inloggen )

edit: het zal in /etc/securetty zijn

[ Voor 10% gewijzigd door Whollabilla op 19-01-2006 19:16 ]

[Verwijderd]

Het zou misschien handig zijn als je vertelde hoe je die accounts aangemaakt hebt.
Kijk bijvoorbeeld eens wat er in /etc/passwd staat over die gebruikers.
En wat staat er in de logs van sshd wanneer je met zon gebruiker in wil loggen?

[BHQ]

Accounts zijn gemaakt met 'adduser'. Ik ga zo ff kijken naar de inhoud van de files.

# Package generated configuration file
# See the sshd( 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
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 768
# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:
LoginGraceTime 600
PermitRootLogin yes
StrictModes yes

RSAAuthentication yes
# 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 no to disable s/key passwords
#ChallengeResponseAuthentication yes

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

# To change Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#AFSTokenPassing no
#KerberosTicketCleanup no

# Kerberos TGT Passing does only work with the AFS kaserver
#KerberosTgtPassing yes

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

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

Subsystem sftp /usr/lib/sftp-server

UsePAM yes
AllowUsers root
AllowUsers admin

Ik denk dat het hem in het laatste zit, en ik wil dat alleen root en de 2 gemaakte users via SSH kunnen inloggen. Kan dat?

[ Voor 93% gewijzigd door BHQ op 19-01-2006 19:35 ]

[Keeper of the Keys]

Je kunt het beste juist root en eigenlijk ook van die standaard namen als 'admin' geen rechten geven om te ssh'en dat is behoorlijk onveilig.
Wat je beter kunt doen is inloggen als jezelf en dan sudo, su of su -c gebruiken om je spullen te doen.

Verder moeten de gebruikers die zijn toegestaan om te ssh'en allemaal op dezelfde regel staan gescheiden door spaties:

code:

AllowUsers naam1 naam2 etc

[JaQ]

Uit de man page:

code:

AllowUsers
This keyword can be followed by any number of user name patterns or user@host patterns, separated by spaces. Host name may be either the dns name or the ip address. If specified, login is allowed only as users whose name matches one of the patterns. '*' and '?' can be used as wildcards in the patterns. By default, logins as all users are allowed.

Je zou die AllowUsers dus eens uit commentarieren (en in ieder geval er 1 regel van maken)

[BHQ]

Dank. Moet ik hierna de sshd nog een rebonk geven?

[Verwijderd]

Yapser schreef op donderdag 19 januari 2006 @ 20:22:
Dank. Moet ik hierna de sshd nog een rebonk geven?

Of een -HUP.

[Verwijderd]

KeeperoftheKeys schreef op donderdag 19 januari 2006 @ 20:07:
Je kunt het beste juist root en eigenlijk ook van die standaard namen als 'admin' geen rechten geven om te ssh'en dat is behoorlijk onveilig.
Wat je beter kunt doen is inloggen als jezelf en dan sudo, su of su -c gebruiken om je spullen te doen.

Wat hierboven staat is tamelijk belangrijk. Naast deze methodes kan je ook natuurlijk ook nog keys gebruiken om in te loggen. Inloggen m.b.v. public keys is sowieso een stuk veiliger dan inloggen met alleen een wachtwoord.

Op dit moment staat direct als root inloggen met password authenticatie aan (PermitRootLogin Yes). Ik raad je aan dit uit te zetten of op "without-password", zodra je weer in kunt loggen als gewone gebruiker indien SSH toegang niet beperkt is tot een aantal IP's.

PermitRootLogin
Specifies whether root can login 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. Note that other authentication methods (e.g., keyboard-interac-
tive/PAM) may still allow root to login using a password.

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 speci-
fied (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 login.

[DeMoN]

Verwijderd schreef op donderdag 19 januari 2006 @ 20:27:
[...]

Op dit moment staat direct als root inloggen met password authenticatie aan (PermitRootLogin Yes). Ik raad je aan dit uit te zetten of op "without-password", zodra je weer in kunt loggen als gewone gebruiker indien SSH toegang niet beperkt is tot een aantal IP's.


[...]

Je hebt gelijk hoor, maar toch heb ik hier af en toe mij twijfels bij.
Stel je gebruikt echt een sterk rootwachtwoord en dan wel in de trant van:
5f03hfW02jc (zoiets gebruik ik bijv.), dan valt dat gewoon niet te achterhalen met brute force / dict attack.

Waarom zou je dat dan alsnog zoveel gaan beveiligen dmv keys e.d?

[GarBaGe]

DeMoN schreef op vrijdag 20 januari 2006 @ 12:13:
[...]
Je hebt gelijk hoor, maar toch heb ik hier af en toe mij twijfels bij.
Stel je gebruikt echt een sterk rootwachtwoord en dan wel in de trant van:
5f03hfW02jc (zoiets gebruik ik bijv.), dan valt dat gewoon niet te achterhalen met brute force / dict attack.

Waarom zou je dat dan alsnog zoveel gaan beveiligen dmv keys e.d?

Een password hoeft maar gesnift te worden en iedereen heeft toegang. Bij public key, wordt het belangrijkste element (de private key) nooit over het netwerk verstuurd. Er worden dus GEEN geheimen over het netwerk verstuurd, dus is het veiliger... (ook al is het maar 1 extra stapje)

[serkoon]

GarBaGe schreef op vrijdag 20 januari 2006 @ 12:21:
[...]
Een password hoeft maar gesnift te worden en iedereen heeft toegang. Bij public key, wordt het belangrijkste element (de private key) nooit over het netwerk verstuurd. Er worden dus GEEN geheimen over het netwerk verstuurd, dus is het veiliger... (ook al is het maar 1 extra stapje)

Dat is nogal kort door de bocht, vind ik. Het idee van SSH is juist dat je password niet gesniffd kan worden. Zolang je er dus voor zorgt dat je password niet over onveilige media gestuurd wordt, is dat geen issue. Wat wel een issue kan zijn is dat je password wordt afgeluisterd op andere manieren, bijvoorbeeld omdat het systeem waar je vandaan komt gehackt is. In dat geval zou ik keys even onveilig, misschien zelfs onveiliger vinden. Een aanvaller kan, als de passphrase eenmaal bekend is geraakt, vaak daarmee op meerdere systemen in 1 klap inloggen. Met goedgekozen passwords die per systeem verschillend zijn, is dat niet zo.

[DeMoN]

serkoon schreef op vrijdag 20 januari 2006 @ 14:28:
[...]

Dat is nogal kort door de bocht, vind ik. Het idee van SSH is juist dat je password niet gesniffd kan worden. Zolang je er dus voor zorgt dat je password niet over onveilige media gestuurd wordt, is dat geen issue. Wat wel een issue kan zijn is dat je password wordt afgeluisterd op andere manieren, bijvoorbeeld omdat het systeem waar je vandaan komt gehackt is. In dat geval zou ik keys even onveilig, misschien zelfs onveiliger vinden. Een aanvaller kan, als de passphrase eenmaal bekend is geraakt, vaak daarmee op meerdere systemen in 1 klap inloggen. Met goedgekozen passwords die per systeem verschillend zijn, is dat niet zo.

Ja idd, dat is precies mijn punt.
Ik heb gewoon root login aan staan op mijn server met een ijzersterk password.

Dan mag nu iemand mij (graag zelfs) overtuigen waarom dat zou gevaarlijk moet zijn

Het gaat hier om een thuisservertje uiteraard.. want bakken op het werk die evt. via SSH naar buiten zouden staan zou ik ook anders inrichten. (iig geen poort 22, geen root login, misschien keys )

[zomertje]

Omdat de gebruikersnaam dan al bekend is? Dan hoeft het wachtwoord alleen nog maar geraden te worden Er zijn ook veel mensen die geen moeilijk wachtwoord nemen, een reden dus om remote root login af te raden. (even in het algemeen, niet zozeer naar de mensen in dit topic) En volgens mij waren ze jaren geleden al zover dat ze het een en ander konden ontcijferen uit ssh1. Gebruik je ook ftp als root, dan gaat je wachtwoord ook gewoon plain over het net (of is dat inmiddels niet meer zo?)

[DeMoN]

zomertje schreef op vrijdag 20 januari 2006 @ 14:36:
Omdat de gebruikersnaam dan al bekend is? Dan hoeft het wachtwoord alleen nog maar geraden te worden Er zijn ook veel mensen die geen moeilijk wachtwoord nemen, een reden dus om remote root login af te raden. (even in het algemeen, niet zozeer naar de mensen in dit topic) En volgens mij waren ze jaren geleden al zover dat ze het een en ander konden ontcijferen uit ssh1. Gebruik je ook ftp als root, dan gaat je wachtwoord ook gewoon plain over het net (of is dat inmiddels niet meer zo?)

Bij FTP, tjsa, normale FTP wel. Dan heb je ook nog FTP over SSL enzo en SFTP.
FTP over SSL (FTPS) heb je volgens mij weer in verschillende smaken. Encryptie op de control channel, op de data channel, of allebei.
SFTP is het meest veilig. Das een soort FTP met SSH security

[zomertje]

DeMoN schreef op vrijdag 20 januari 2006 @ 15:32:
[...]


Bij FTP, tjsa, normale FTP wel. Dan heb je ook nog FTP over SSL enzo en SFTP.
FTP over SSL (FTPS) heb je volgens mij weer in verschillende smaken. Encryptie op de control channel, op de data channel, of allebei.
SFTP is het meest veilig. Das een soort FTP met SSH security

Dat bedoelde ik ja, normale FTP, vaak wordt het namelijk gewoon over het hoofd gezien

[Verwijderd]

DeMoN schreef op vrijdag 20 januari 2006 @ 12:13:
Je hebt gelijk hoor, maar toch heb ik hier af en toe mij twijfels bij.
Stel je gebruikt echt een sterk rootwachtwoord en dan wel in de trant van:
5f03hfW02jc (zoiets gebruik ik bijv.), dan valt dat gewoon niet te achterhalen met brute force / dict attack.

De praktijk leert alleen dat dergelijke wachtwoorden lang niet altijd gebruikt worden
In theorie is het wachtwoordt natuurlijk nog steeds te kraken.

Wat doe je echter als ik over je schouder meekijk terwijl je het wachtwoord intikt? Of wanneer je het wachtwoord op meerdere plaatsen gebruikt, waarbij ik op de een of andere manier het wachtwoord onderschep?

Waarom zou je dat dan alsnog zoveel gaan beveiligen dmv keys e.d?

Als je key-based authentication gebruikt, dan moet je naast de passprase ook nog in het bezit zijn van de niet al te publieke "public" key.

Daarnaast komen keys pas echt goed naar voren in multi-user omgevingen.
Iedere gebruiker en/of beheerder kan namelijk zijn eigen key en passphrase gebruiken, waardoor de kans op het in verkeerde handen vallen van login-gegevens beduidend geminimaliseerd wordt.

En dan hebben we het nog niet eens gehad over het feit dat je met keys ook beperkingen aan accounts op kunt leggen

zomertje schreef op vrijdag 20 januari 2006 @ 16:16:
[...]


Dat bedoelde ik ja, normale FTP, vaak wordt het namelijk gewoon over het hoofd gezien

Elk systeem en elke stukje software dat over een unencrypted connectie inloggen als een superuser toestaat mag wat mij betreft meteen verbannen worden

[ Voor 6% gewijzigd door Verwijderd op 20-01-2006 19:02 ]