SSH public key werkt niet zonder passwordauthentication

[MoiZie]

Topic title says it all...

Ik probeer nu al een tijdje mijn OpenSSH server te beveiligen, door alleen public key authenticatie toe te staan. Als ik nu ssh inlog op mijn ip adres (remote) krijg ik heel netjes de melding: "geef het wachtwoord voor de gebruikerskey die en die". Daarna moet ik nog het userwachtwoord voor de server-user intypen. Dit omdat ik 'PasswordAuthentication yes' in mijn config file (/etc/ssh/sshd_config) heb staan. Dat wil ik natuurlijk niet .

Echter

code:

Port ;)
Protocol 2
SyslogFacility AUTH
LogLevel INFO
LoginGraceTime 120
PermitRootLogin no
StrictModes yes
PasswordAuthentication no
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile      /home/moizie/.ssh/authorized_keys
PermitEmptyPasswords no
Banner /etc/issue.net

op deze manier werkt het niet meer! Het enige verschil met de situatie hiervooor beschreven is de verandering van PasswordAuthentication yes naar no. Nu gebeurt er bij een restart van ssh het volgende: wachtwoord moeten invullen van die specifieke key, en dan een Permission denied (publickey,keyboard-interactive).

Ik weet echt niet waar ik het nog kan zoeken.. Heb https://help.ubuntu.com/community/SSH/OpenSSH/Configuring en https://help.ubuntu.com/community/SSH/OpenSSH/Keys voor mijn gevoel helemaal gevolgd.. Het feit dat ik gewoon kan inloggen met de key (toch? of gebruikt hij de user/pass als fallback omdat het toch niet werkt?) lijkt me dat dat wel in orde is.

Eventueel wil ik wel een ssh -v of -vvv geven, maar dat is een flinke lap tekst

[gertvdijk]

Laat allereerst duidelijk zijn dat het wachtwoord dat je invoert voor je key het wachtwoord (passphrase) is waarmee je je key hebt geëncrypt. Het wachtwoord dat je erna moet invoeren is de fallback en een gewone SSH authenticatie.

MoiZie schreef op donderdag 09 juli 2009 @ 21:56:
Eventueel wil ik wel een ssh -v of -vvv geven, maar dat is een flinke lap tekst

Daaruit zal blijken dat public key auth niet goed gaat en dat hij terugvalt op de methode met het wachtwoord.
Je moet kijken op de server wat de melding is in /var/log/auth.log. Waarschijnlijk zal je daarin iets zien staan over verkeerde user rights op de ~/.ssh directory of ~/.ssh/authorized_keys file. (gokje)

Verder klopt je sshd_config voor geen meter. Je wil niet dat elke user gaat inloggen tegen jouw authorized keys. 'AuthorizedKeysFile' moet gewoon gecomment zijn.

Oftewel: lees beter de how-to's die je zelf al aangedragen hebt en doe vooral geen dingen die er niet in staan. Verder is de output van /var/log/auth.log op de server heel interessant.

P.S. Voor lappen tekst hebben we pastebin

[ Voor 22% gewijzigd door gertvdijk op 09-07-2009 23:14 ]

[John_Glenn]

Volgens mij gaat er iets mis met je public key gebeuren - want ook met PasswordAuthentication yes zou hij niet om dat tweede password meer moeten vragen: die optie betekent alleen dat je password-logins toestaat, niet dat je steeds allebei moet gebruiken. Dus inderdaad zoals je al zegt, zie ik net: hij gebruikt de user/pass als fallback.

Edit: ^^ what he says...

[ Voor 4% gewijzigd door John_Glenn op 09-07-2009 23:14 ]

[MoiZie]

gertvdijk schreef op donderdag 09 juli 2009 @ 23:08:
Laat allereerst duidelijk zijn dat het wachtwoord dat je invoert voor je key het wachtwoord (passphrase) is waarmee je je key hebt geëncrypt. Het wachtwoord dat je erna moet invoeren is de fallback en een gewone SSH authenticatie.

[...]

Daaruit zal blijken dat public key auth niet goed gaat en dat hij terugvalt op de methode met het wachtwoord.
Je moet kijken op de server wat de melding is in /var/log/auth.log. Waarschijnlijk zal je daarin iets zien staan over verkeerde user rights op de ~/.ssh directory of ~/.ssh/authorized_keys file. (gokje)

Verder klopt je sshd_config voor geen meter. Je wil niet dat elke user gaat inloggen tegen jouw authorized keys. 'AuthorizedKeysFile' moet gewoon gecomment zijn.

Oftewel: lees beter de how-to's die je zelf al aangedragen hebt en doe vooral geen dingen die er niet in staan. Verder is de output van /var/log/auth.log op de server heel interessant.

P.S. Voor lappen tekst hebben we pastebin

Ik heb de originele sshd_config teruggezet en #AuthorizedKeysFile gedingest. Ik had uit wanhoop geprobeerd zoveel mogelijk weg te gooien uit de sshd_config file, zodat alles zoveel mogeijk gedefault werd.

code:

Jul  9 23:32:11 Server sshd[27468]: error: RSA_public_decrypt failed: error:0407006A:lib(4):func(112):reason(106)
Jul  9 23:32:15 Server sshd[27468]: Accepted password for moizie from 8*.8*.1**.1* port 9319 ssh2

Dat gebeurt er als ik probeer te connecten. In ieder geval, ik zit in ssh te kijken en intussen open ik een nieuwe ssh verbinding (andere terminal) en dat verandert er.

[gertvdijk]

MoiZie schreef op donderdag 09 juli 2009 @ 23:33:
Dat gebeurt er als ik probeer te connecten. In ieder geval, ik zit in ssh te kijken en intussen open ik een nieuwe ssh verbinding (andere terminal) en dat verandert er.

Dan heb je niet goed je public key gekopieerd naar je authorized_keys file op de server. Hij moet er ongeveer zo uitzien:

ssh-rsa AAAAB3Nza[...]paZB63SQ== <commentaar>

en dan precies 1 key per regel.
Of je loopt tegen deze bug aan. Met andere woorden: wat heb je al gegoogled op die foutmelding in je auth.log? Veelal is het probleem dat de public key (id_rsa.pub) niet hoort bij de private key (id_rsa) of dat een van de twee corrupt is geraakt.
Probeer eens handmatig de private key mee te geven als je connect:

ssh -v -i ~/.ssh/id_rsa user@host

MoiZie schreef op donderdag 09 juli 2009 @ 23:33:
Ik heb de originele sshd_config teruggezet en #AuthorizedKeysFile gedingest. Ik had uit wanhoop geprobeerd zoveel mogelijk weg te gooien uit de sshd_config file, zodat alles zoveel mogeijk gedefault werd.

Kalmte kan je redden, joh. Gewoon de default sshd_config is *prima* voor authenticatie met keys. Alleen wanneer je password authenticatie uit wil hebben moet je dat wijzigen en root login verbieden.

Oftewel de volgende checklist als het niet lukt:

• Staat de public key (id_rsa.pub) goed op de server in ~/.ssh/authorized_keys?
• Staan de rechten van de directories goed? op de server: ~ mag niet group/others writeable zijn, ~/.ssh moet 0700 zijn en ~/.ssh/* moet 0600 zijn.
• Weet je zeker dat de public key hoort bij de private key die de client pakt bij het verbinden? Een tweede keer genereren van de keys overschrijft mogelijk je private key, maar er staat nog de oude public key op de server.
• Keys gemaakt met ssh-keygen? (goed!) Of met een raar ander tooltje? (fout!)

Algemene tip: maak een ~./ssh/config aan (op de client) met al je voorkeuren voor al je hosts. Dit maakt het leven veel gemakkelijker. Zie voor de opties

man ssh_config # dus niet sshd_config, die is voor de server-side config

.

[ Voor 76% gewijzigd door gertvdijk op 10-07-2009 00:30 ]

[Verwijderd]

Dit is de sshd config zoals ik die meestal als basis gebruik. Je hoeft alleen deze dingen te veranderen en daarna open-ssh restarten.

PermitRootLogin no
PasswordAuthentication no

code:

# Package generated configuration file
# See the sshd(8) 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 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 120
PermitRootLogin no
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 no

# 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

MaxAuthTries 2
#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

UsePAM yes

Staan verder der permissies van de .ssh dir en de authorized_keys file van de betreffende user wel goed?

chmod 0700 .ssh
chmod 0600 .ssh/authorized_keys

[Verwijderd]

Je hebt toch niet een key met putty gemaakt he? Als dat wel het geval is dan weet ik meteen waar het probleem zit

[gertvdijk]

Verwijderd schreef op vrijdag 10 juli 2009 @ 00:22:
Je hebt toch niet een key met putty gemaakt he? Als dat wel het geval is dan weet ik meteen waar het probleem zit

Haha ja, een klassieke fout.
Welke malloot bij PuTTY heeft ooit bedacht om keys in een ander formaat te gaan maken?

[Verwijderd]

Inderdaad Gert. Ik ben daar zelf ook eens ingestonken, heeft me een uur gekost ofzo

[MoiZie]

gertvdijk schreef op donderdag 09 juli 2009 @ 23:49:
[...]

Dan heb je niet goed je public key gekopieerd naar je authorized_keys file op de server. Hij moet er ongeveer zo uitzien:

ssh-rsa AAAAB3Nza[...]paZB63SQ== <commentaar>

en dan precies 1 key per regel.

Jawel . id_rsa.pub ge-scpt en cat naar authorized_keys. Later zelfs nog via vi authorized_keys erin geplakt.

Of je loopt tegen deze bug aan. Met andere woorden: wat heb je al gegoogled op die foutmelding in je auth.log?

Nog niets, het was gisteravond half 12 zoals je kan zien, dus ik heb alleen nog even snel gepost wat ik in het .log bestand vond.

Veelal is het probleem dat de public key (id_rsa.pub) niet hoort bij de private key (id_rsa) of dat een van de twee corrupt is geraakt.
Probeer eens handmatig de private key mee te geven als je connect:

ssh -v -i ~/.ssh/id_rsa user@host

ssh-copy-id toch?

[...]

Kalmte kan je redden, joh. Gewoon de default sshd_config is *prima* voor authenticatie met keys. Alleen wanneer je password authenticatie uit wil hebben moet je dat wijzigen en root login verbieden.

Ik werk natuurlijk vanuit de default file, die rechtstreeks met aptitude install openssh-server geinstalleerd is . Daarin staat root login automatisch op no en als ik PublickeyAuthentication yes decomment, en PasswordAuthentication verander in no, krijg ik bovenstaand vermeld probleem.

Oftewel de volgende checklist als het niet lukt:

• Staat de public key (id_rsa.pub) goed op de server in ~/.ssh/authorized_keys? JA
• Staan de rechten van de directories goed? op de server: ~ mag niet group/others writeable zijn, ~/.ssh moet 0700 zijn en ~/.ssh/* moet 0600 zijn. JA
• Weet je zeker dat de public key hoort bij de private key die de client pakt bij het verbinden? Een tweede keer genereren van de keys overschrijft mogelijk je private key, maar er staat nog de oude public key op de server. JA
• Keys gemaakt met ssh-keygen? (goed!) Of met een raar ander tooltje? (fout!) JA

Algemene tip: maak een ~./ssh/config aan (op de client) met al je voorkeuren voor al je hosts. Dit maakt het leven veel gemakkelijker. Zie voor de opties

man ssh_config # dus niet sshd_config, die is voor de server-side config

.

Ik zal eens kijken naar man ssh_config.

Verwijderd schreef op donderdag 09 juli 2009 @ 23:52:
Dit is de sshd config zoals ik die meestal als basis gebruik. Je hoeft alleen deze dingen te veranderen en daarna open-ssh restarten.

PermitRootLogin no
PasswordAuthentication no

code:

Met uitzondering van UsePAM yes is dat de default file ja.

Staan verder der permissies van de .ssh dir en de authorized_keys file van de betreffende user wel goed?

chmod 0700 .ssh
chmod 0600 .ssh/authorized_keys

Ja
ls -al bevestigt dit.

En nee, geen key gemaakt met putty. (Noujah, ik heb er wel 1 gemaakt, maar op een windows pc, die key ziet er desalniettemin hetzelfde uit als die ik genereer via ssh-keygen op de linux pc vanwaar dit probleem ontstaat. Toch krijg ik ook via putty de melding dat ik mijn password moet invoeren. Ik weet ook wel zeker dat die key van putty werkt, als ik de key namelijk helemaal niet mee geef, krijg ik meteen een permission denied.)


Edit: Oh! Iets wat ik vergeten ben te zeggen, ik probeer vanaf Karmic Koala x64 te verbinden met Jaunty Jackalope x32.

[gertvdijk]

MoiZie schreef op vrijdag 10 juli 2009 @ 10:12:
ssh-copy-id toch?

Dat is heel wat anders. Ik bedoel met 'ssh -i' dat je expliciet de private key opgeeft in plaats van dat ssh maar misschien de defauld id_rsa key gaat pakken. Gewoon om wat uit te sluiten.

MoiZie schreef op vrijdag 10 juli 2009 @ 10:12:
Edit: Oh! Iets wat ik vergeten ben te zeggen, ik probeer vanaf Karmic Koala x64 te verbinden met Jaunty Jackalope x32.

Probeer het eens te doen met Jaunty-Jaunty. Karmic is nog heel heel erg alpha.

[MoiZie]

Hm, ik heb nu vanaf een andere (jaunty) pc geprobeerd te connecten nadat ik de key op de server heb gezet, en dat werkt zonder problemen. Ook zonder passphrase dus. Nu eens even passwordauthentication op no zetten en kijken of hij nog steeds blijft werken.

Edit: ja dus.. Wat is er dan mis met de key op de karmic pc? Een foutje in de client misschien?

[ Voor 16% gewijzigd door MoiZie op 10-07-2009 13:33 ]

[gertvdijk]

MoiZie schreef op vrijdag 10 juli 2009 @ 13:32:
Wat is er dan mis met de key op de karmic pc? Een foutje in de client misschien?

Die key is blijkbaar niet goed. Corrupt of met een incompatibel formaat voor de OpenSSH versie van Jaunty. Nogmaals: Karmic is heel heel erg alpha en je hoeft mag daarom niet te verwachten dat alles zomaar werkt. Plaats een bugreport op launchpad als je nog geen reeds bestaande bugreport kan vinden erover, zou ik zeggen.

[MoiZie]

Hm, en als een workaround, kan ik de id_rsa kopiëren naar de jaunty pc, en daar dan ssh-keygen op draaien? En dan de hele zwik weer terugkopiëren? Of nog beter, de inhoud van id_rsa en id_rsa.pub van de jaunty naar de karmic kopiëren? Ik zit nu niet thuis, dus kan het niet proberen, maar ik vroeg me af of zoiets in theorie mogelijk is. Of worden dat soort dingen gemaakt met hardware-ID's en zo, tijd, datum, dat soort dingen?

[Verwijderd]

Keys zijn uitwisselbaar tussen alle distro's en distro versies. ssh-keygen maakt gebruik van de random number generator /dev/random

[Boudewijn]

MoiZie schreef op vrijdag 10 juli 2009 @ 21:31:
Hm, en als een workaround, kan ik de id_rsa kopiëren naar de jaunty pc, en daar dan ssh-keygen op draaien? En dan de hele zwik weer terugkopiëren? Of nog beter, de inhoud van id_rsa en id_rsa.pub van de jaunty naar de karmic kopiëren? Ik zit nu niet thuis, dus kan het niet proberen, maar ik vroeg me af of zoiets in theorie mogelijk is. Of worden dat soort dingen gemaakt met hardware-ID's en zo, tijd, datum, dat soort dingen?

Dat is uitwisselbaar.

Sowieso: het wordt gebruikt door 2 machines.... als in: 1 waarop de public en 1 waarop de private key staat.

[gertvdijk]

MoiZie schreef op vrijdag 10 juli 2009 @ 21:31:
Hm, en als een workaround, kan ik de id_rsa kopiëren naar de jaunty pc, en daar dan ssh-keygen op draaien?

Met ssh-keygen maak je een nieuwe key, dus dan hoef je id_rsa niet te gaan kopiëren, hoor.

MoiZie schreef op vrijdag 10 juli 2009 @ 21:31:
Of nog beter, de inhoud van id_rsa en id_rsa.pub van de jaunty naar de karmic kopiëren?

Dat lijkt mij een goed idee.

MoiZie schreef op vrijdag 10 juli 2009 @ 21:31:
Ik zit nu niet thuis, dus kan het niet proberen, maar ik vroeg me af of zoiets in theorie mogelijk is. Of worden dat soort dingen gemaakt met hardware-ID's en zo, tijd, datum, dat soort dingen?

Een key is niets meer dan random data met RSA versleuteld. Wel is het verstandig om private keys niet overal en nergens naar toe te kopiëren. Soms kan je er beter voor kiezen om voor elk systeem een aparte key te maken.

[Guru Evi]

SSH keys - eenvoudig:

1) Laat de standaard config staan - je backup hiervan herstellen zou al kunnen helpen, herstart sshd
2) Login op de server en open een terminal op de client en doe "rm ~/.ssh/*" op beide machines
3) ssh-keygen - ik doe het op beide machines - als je een Windows systeem hebt gebruik je beter Cygwin met OpenSSH, indien je een passphrase wilt om je key te beschermen kun je dit nog steeds.
4) Verbind met de 'server' via normale authenticatie naar de gebruiker die je wilt (ssh user@host)

code:

cd ~/.ssh
pico ~/.ssh/authorized_keys

kopieer de inhoud van ~/.ssh/id_rsa.pub (niet id_rsa) op de client in het bestand dat je openstaan hebt op de server

Dat is alles dat je moet doen. Als er nog errors zijn kun je het alsnog posten. Achteraf kun je dan nog prutsen met Putty of andere SSH clients, gewoon de locatie van id_rsa en id_rsa.pub meegeven aan Putty zou moeten werken. Als dat werkt, dan op de SSH server kun je beginnen prutsen met het uitzetten van bepaalde authenticatie middelen. Let wel dat het soms wel terug kan bijten als je op een locatie bent en je je keys niet meehebt, voor mij zijn keys een gemak - geen passphrase, gewoon "ssh host" en ik ben binnen zonder iets anders te typen. Ik heb gewoon gezorgd dat bij 3 verkeerde authenticaties de host wordt geblokkeerd voor een uurtje en natuurlijk geen zwakke paswoorden gebruiken.

Als je een passphrase hebt gemaakt tijdens ssh-keygen kan het nog steeds zijn dat je een paswoord moet geven alvorens de key kan gedecrypt worden, dat paswoord gaat echter niet over de lijn.

[ Voor 4% gewijzigd door Guru Evi op 11-07-2009 05:46 ]

[gertvdijk]

Guru Evi schreef op zaterdag 11 juli 2009 @ 05:42:
Als je een passphrase hebt gemaakt tijdens ssh-keygen kan het nog steeds zijn dat je een paswoord moet geven alvorens de key kan gedecrypt worden, dat paswoord gaat echter niet over de lijn.

Ik wil je sterk aanraden om *wel* een passphrase te gaan gebruiken. Mocht je private key ooit eens op straat komen dan heb je namelijk echt een probleem als hij niet encrypted is. Je kan overigens in Gnome gewoon aangeven dat hij dat passphrase opslaat tot het einde van je sessie of zelfs decrypt bij inloggen. Dus 'telkens passphrase moeten intypen' vind ik geen excuus.

[Borromini]

Keys zonder passphrase zijn waardeloos. Het is non-security. De meeste mensen gebruiken het dan ook alleen maar louter omdat ze zo het ingeven van het paswoord kunnen omzeilen (door keys te genereren zonder passphrase).

Als het ingeven van de passphrase/het paswoord je irriteert is er altijd ssh-add, of zoals hierboven gezegd, Gnomes eigen utilities.

Ik gebruik hier ssh-add en ik ben er heel erg tevreden over - één keer toevoegen, ssh-agent slaat ze op, elke keer dat je ssh aanroept logt ie je gewoon automatisch in. Makkelijk zat. Dat moet je natuurlijk weer elke sessie opnieuw doen, maar daarvoor hebben ze dan ook de suspend modes uitgevonden .

[ Voor 9% gewijzigd door Borromini op 11-07-2009 13:31 ]

[MoiZie]

Ik ben helemaal flabbergasted.. Ik kan nu namelijk alleen nog maar inloggen met wachtwoord. Ik heb een reinstall gedaan van ssh, waarbij ik alle config files eerst weg heb gegooid (die in /etc/ssh/ ), zodat alle default config files weer terug komen. Ik kan nu op afstand inloggen, maar alleen met wachtwoord.

Allebei de keys van de Jaunty en Karmic clients staan keurig in authorized_keys. Die bestanden heb ik niets aan gewijzigd. Ik heb wat hekjes weggehaald in ssh_config en sshd_config, zodat PubkeyAuthentication op yes nu niet weggecomment is e.d..

code:

# This is the ssh client system-wide configuration file.  See
# ssh_config(5) for more information.  This file provides defaults for
# users, and the values can be changed in per-user configuration files
# or on the command line.

# Configuration data is parsed as follows:
#  1. command line options
#  2. user-specific file
#  3. system-wide file
# Any configuration value is only changed the first time it is set.
# Thus, host-specific definitions should be at the beginning of the
# configuration file, and defaults at the end.

# Site-wide defaults for some commonly used options.  For a comprehensive
# list of available options, their meanings and defaults, please see the
# ssh_config(5) man page.

Host *
#   ForwardAgent no
#   ForwardX11 yes
#   ForwardX11Trusted yes
#   RhostsRSAAuthentication no
#   RSAAuthentication yes
#   PasswordAuthentication no
#   HostbasedAuthentication no
#   GSSAPIAuthentication no
#   GSSAPIDelegateCredentials no
#   GSSAPIKeyExchange no
#   GSSAPITrustDNS no
#   BatchMode no
#   CheckHostIP yes
#   AddressFamily any
#   ConnectTimeout 0
#   StrictHostKeyChecking ask
#   IdentityFile ~/.ssh/identity
#   IdentityFile ~/.ssh/id_rsa
#   IdentityFile ~/.ssh/id_dsa
   Port 22
   Protocol 2
#   Cipher 3des
#   Ciphers aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,ae$
#   MACs hmac-md5,hmac-sha1,[e-mail],hmac-ripemd160
#   EscapeChar ~
#   Tunnel no
#   TunnelDevice any:any
#   PermitLocalCommand no
#    SendEnv LANG LC_*
#    HashKnownHosts yes
#    GSSAPIAuthentication yes
#    GSSAPIDelegateCredentials no
PubkeyAuthentication yes
LogLevel Verbose
PreferredAuthentication publickey, password
User moizie

Dit is mijn ssh_config bestand.

code:

# Package generated configuration file
# See the sshd(8) 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 VERBOSE

# Authentication:
LoginGraceTime 120
PermitRootLogin no
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile      /home/moizie/.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

# 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

En dat was mijn sshd_config bestand. Ik zie het echt niet meer.. Ik heb toch PubkeyAuthentication aan staan? Dat PasswordAuthentication ook op yes staat is nu een noodzaak, anders kom ik niet meer bij de server (en die is niet om de hoek..).

[gertvdijk]

Je hebt het weer niet gesnapt. Post nou eens informatie waar we wat aan hebben: de output van de client bij het inloggen en de logs op de server als de pubkey auth faalt.
Daarnaast:

• Je client is Jaunty of Karmic?
• Wat doet de client als je expliciet je private key opgeeft: 'IdentityFile ~/.ssh/id_rsa'?
• Waar zet je die ssh_config? Het hoort in in ~/.ssh/config, want het is een persoonlijke config imo, en overruled de system-wide config:

  ssh(1) obtains configuration data from the following sources in the fol‐
       lowing order:
  
             1.   command-line options
             2.   user’s configuration file (~/.ssh/config)
             3.   system-wide configuration file (/etc/ssh/ssh_config)

• Waar heb je die ssh_config file vandaan? Het is namelijk niet 'PreferredAuthentication', maar 'PreferredAuthentications'. Waarschijnlijk zie je ook een melding verschijnen dat die config optie niet bestaat in de output van je terminal als je connect als je dat met verbose output doet.

[ Voor 51% gewijzigd door gertvdijk op 14-07-2009 11:46 ]

[Boudewijn]

Borromini schreef op zaterdag 11 juli 2009 @ 13:30:
Keys zonder passphrase zijn waardeloos. Het is non-security. De meeste mensen gebruiken het dan ook alleen maar louter omdat ze zo het ingeven van het paswoord kunnen omzeilen (door keys te genereren zonder passphrase).

Ik gebruik hier ssh-add en ik ben er heel erg tevreden over - één keer toevoegen, ssh-agent slaat ze op, elke keer dat je ssh aanroept logt ie je gewoon automatisch in. Makkelijk zat. Dat moet je natuurlijk weer elke sessie opnieuw doen, maar daarvoor hebben ze dan ook de suspend modes uitgevonden .

Keys zonder passphrase hebben wel nut.

Je moet nog steeds de keyfile hebben, en brute forcen is niet mogelijk.
Je maakt het echter wel makkelijk te misbruiken als iemand eenmaal die keyfile heeft (gehad).

[gertvdijk]

Boudewijn schreef op dinsdag 14 juli 2009 @ 11:51:
Keys zonder passphrase hebben wel nut.

Hoewel beetje offtopic... Optimale beveiliging bestaat uit de combinatie van het overleggen van de volgende punten:

1. Iets dat bewijst dat jij bent die je zegt te zijn.
   Voorbeeld: vingerafdruk, irisscan.
2. Iets dat je moet hebben voor de betreffende actie.
   Voorbeeld: een vooraf overeengekomen key.
3. Iets dat je moet weten.
   Voorbeeld: een wachtwoord, passphrase of pincode

Hoe meer van deze punten (correct) worden toegepast, hoe beter de beveiliging is geregeld (in beginsel en theorie). Dat je 1) en 2) niet kan uitwisselen komt door het feit dat 1) niet te revoken is en 2) dit wel is. Dat is ook gelijk de zwakte van alleen-vingerafdruk authenticatie en met name de illusie die sommige mensen hebben dat dit wel goed is is erg dom.

[ Voor 20% gewijzigd door gertvdijk op 14-07-2009 12:07 ]

[Verwijderd]

Keys zonder passphrase worden vaak gebruikt om backups door een ssh tunnel te laten lopen. Op zich is deze methode alleen redelijk veilig in combinatie met ssh forced commands in je key en een allowusers [e-mail] regel in je sshd_config.

Helaas zie je in de praktijk dat mensen een key zonder passphrase aanmaken en klaar Laat ik het zo zeggen die zullen het nooit snappen.

Btw forced commands is een heel krachtig middel die een attack redelijk kansloos maakt

[MoiZie]

gertvdijk schreef op dinsdag 14 juli 2009 @ 11:39:
Je hebt het weer niet gesnapt.

Sorry hoor .

Post nou eens informatie waar we wat aan hebben: de output van de client bij het inloggen en de logs op de server als de pubkey auth faalt.

Ok, here goes, een complete lijst van ssh -vvv *host*

code:

OpenSSH_5.1p1 Debian-5ubuntu1, OpenSSL 0.9.8g 19 Oct 2007        
debug1: Reading configuration data /etc/ssh/ssh_config           
debug1: Applying options for *                                   
debug2: ssh_connect: needpriv 0                                  
debug1: Connecting to    
debug1: Connection established.                                  
debug3: Not a RSA1 key file /home/moizie/.ssh/id_rsa.            
debug2: key_type_from_name: unknown key type '-----BEGIN'        
debug3: key_read: missing keytype                                
debug2: key_type_from_name: unknown key type 'Proc-Type:'        
debug3: key_read: missing keytype                                
debug2: key_type_from_name: unknown key type 'DEK-Info:'         
debug3: key_read: missing keytype                                
debug3: key_read: missing whitespace                             
debug3: key_read: missing whitespace                             
debug3: key_read: missing whitespace                             
debug3: key_read: missing whitespace                             
debug3: key_read: missing whitespace                             
debug3: key_read: missing whitespace                             
debug3: key_read: missing whitespace                             
debug3: key_read: missing whitespace                             
debug3: key_read: missing whitespace                             
debug3: key_read: missing whitespace                             
debug3: key_read: missing whitespace                             
debug3: key_read: missing whitespace                             
debug3: key_read: missing whitespace                             
debug3: key_read: missing whitespace                             
debug3: key_read: missing whitespace                             
debug3: key_read: missing whitespace                             
debug3: key_read: missing whitespace                             
debug3: key_read: missing whitespace                             
debug3: key_read: missing whitespace                             
debug3: key_read: missing whitespace                             
debug3: key_read: missing whitespace                             
debug3: key_read: missing whitespace                             
debug3: key_read: missing whitespace                             
debug3: key_read: missing whitespace                             
debug3: key_read: missing whitespace                             
debug2: key_type_from_name: unknown key type '-----END'          
debug3: key_read: missing keytype                                
debug1: identity file /home/moizie/.ssh/id_rsa type 1            
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048      
debug1: identity file /home/moizie/.ssh/id_dsa type -1           
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1p1 Debian-5ubuntu1                                                                    
debug1: match: OpenSSH_5.1p1 Debian-5ubuntu1 pat OpenSSH*                      
debug1: Enabling compatibility mode for protocol 2.0                           
debug1: Local version string SSH-2.0-OpenSSH_5.1p1 Debian-5ubuntu1             
debug2: fd 3 setting O_NONBLOCK                                                
debug1: SSH2_MSG_KEXINIT sent                                                  
debug1: SSH2_MSG_KEXINIT received                                              
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1     
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss                                     
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,[e-mail],aes128-ctr,aes192-ctr,aes256-ctr                                                     
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,[e-mail],aes128-ctr,aes192-ctr,aes256-ctr                                                     
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[e-mail],hmac-ripemd160,[e-mail],hmac-sha1-96,hmac-md5-96                          
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[e-mail],hmac-ripemd160,[e-mail],hmac-sha1-96,hmac-md5-96                          
debug2: kex_parse_kexinit: none,[e-mail],zlib                          
debug2: kex_parse_kexinit: none,[e-mail],zlib                          
debug2: kex_parse_kexinit:                                                     
debug2: kex_parse_kexinit:                                                     
debug2: kex_parse_kexinit: first_kex_follows 0                                 
debug2: kex_parse_kexinit: reserved 0                                          
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1     
debug2: kex_parse_kexinit: ssh-rsa                                             
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,[e-mail],aes128-ctr,aes192-ctr,aes256-ctr                                                     
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,[e-mail],aes128-ctr,aes192-ctr,aes256-ctr                                                     
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[e-mail],hmac-ripemd160,[e-mail],hmac-sha1-96,hmac-md5-96                          
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[e-mail],hmac-ripemd160,[e-mail],hmac-sha1-96,hmac-md5-96                          
debug2: kex_parse_kexinit: none,[e-mail]                               
debug2: kex_parse_kexinit: none,[e-mail]                               
debug2: kex_parse_kexinit:                                                     
debug2: kex_parse_kexinit:                                                     
debug2: kex_parse_kexinit: first_kex_follows 0                                 
debug2: kex_parse_kexinit: reserved 0                                          
debug2: mac_setup: found hmac-md5                                              
debug1: kex: server->client aes128-cbc hmac-md5 none                           
debug2: mac_setup: found hmac-md5                                              
debug1: kex: client->server aes128-cbc hmac-md5 none                           
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent                       
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP                                    
debug2: dh_gen_key: priv key bits set: 125/256                                 
debug2: bits set: 469/1024                                                     
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent                                          
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY                                    
debug3: check_host_in_hostfile: filename /home/moizie/.ssh/known_hosts         
debug3: check_host_in_hostfile: match line 1                                   
debug3: check_host_in_hostfile: filename /home/moizie/.ssh/known_hosts         
debug3: check_host_in_hostfile: match line 2                                   
debug1: Host 'moizie.hopto.org' is known and matches the RSA host key.         
debug1: Found key in /home/moizie/.ssh/known_hosts:1                           
debug2: bits set: 525/1024                                                     
debug1: ssh_rsa_verify: signature correct                                      
debug2: kex_derive_keys                                                        
debug2: set_newkeys: mode 1                                                    
debug1: SSH2_MSG_NEWKEYS sent                                                  
debug1: expecting SSH2_MSG_NEWKEYS                                             
debug2: set_newkeys: mode 0                                                    
debug1: SSH2_MSG_NEWKEYS received                                              
debug1: SSH2_MSG_SERVICE_REQUEST sent                                          
debug2: service_accept: ssh-userauth                                           
debug1: SSH2_MSG_SERVICE_ACCEPT received                                       
debug2: key: /home/moizie/.ssh/id_rsa (0x7fe78f3ceb20)                         
debug2: key: /home/moizie/.ssh/id_dsa ((nil))                                  
debug3: input_userauth_banner                                                  
debug1: Authentications that can continue: publickey,password,keyboard-interactive                                                                            
debug3: start over, passed a different list publickey,password,keyboard-interactive                                                                           
debug3: preferred gssapi-keyex,gssapi-with-mic,gssapi,publickey,keyboard-interactive,password                                                                 
debug3: authmethod_lookup publickey                                            
debug3: remaining preferred: keyboard-interactive,password                     
debug3: authmethod_is_enabled publickey                                        
debug1: Next authentication method: publickey                                  
debug1: Offering public key: /home/moizie/.ssh/id_rsa                          
debug3: send_pubkey_test                                                       
debug2: we sent a publickey packet, wait for reply                             
debug1: Authentications that can continue: publickey,password,keyboard-interactive                                                                            
debug1: Trying private key: /home/moizie/.ssh/id_dsa                           
debug3: no such identity: /home/moizie/.ssh/id_dsa                             
debug2: we did not send a packet, disable method                               
debug3: authmethod_lookup keyboard-interactive                                 
debug3: remaining preferred: password                                          
debug3: authmethod_is_enabled keyboard-interactive                             
debug1: Next authentication method: keyboard-interactive                       
debug2: userauth_kbdint                                                        
debug2: we sent a keyboard-interactive packet, wait for reply                  
debug1: Authentications that can continue: publickey,password,keyboard-interactive                                                                            
debug3: userauth_kbdint: disable: no info_req_seen                             
debug2: we did not send a packet, disable method                               
debug3: authmethod_lookup password                                             
debug3: remaining preferred:                                                   
debug3: authmethod_is_enabled password                                         
debug1: Next authentication method: password                                   
moizie@Server password:

Wat ik raar vind is de melding aan het begin, bla bla is geen RSA1 key, ik heb gewoon ssh-keygen gedraaid, alles enter (default) en een wachtwoord ingetypt 2x.

Daarnaast:

• Je client is Jaunty of Karmic? Beide, het werkt vanaf beide niet meer.
• Wat doet de client als je expliciet je private key opgeeft: 'IdentityFile ~/.ssh/id_rsa'? "ssh -i /home/moizie/.ssh/id_rsa.pub host" geeft een wachtwoord prompt, geen publickey passphrase.
• Waar zet je die ssh_config? Het hoort in in ~/.ssh/config, want het is een persoonlijke config imo, en overruled de system-wide config:

  ssh(1) obtains configuration data from the following sources in the fol‐
       lowing order:
  
             1.   command-line options
             2.   user’s configuration file (~/.ssh/config)
             3.   system-wide configuration file (/etc/ssh/ssh_config)

  
  Deze staat standaard in /etc/ssh/, hij kan er ook makkelijk blijven staan, aangezien er maar 1 user is.
• Waar heb je die ssh_config file vandaan? Het is namelijk niet 'PreferredAuthentication', maar 'PreferredAuthentications'. Waarschijnlijk zie je ook een melding verschijnen dat die config optie niet bestaat in de output van je terminal als je connect als je dat met verbose output doet.
  Dat zou dan een foutje van mij zijn, ik heb vanochtend via "man ssh_config" alle opties die ik wil erin proberen te zetten. S vergeten dus.

[gertvdijk]

MoiZie schreef op dinsdag 14 juli 2009 @ 15:04:
Wat ik raar vind is de melding aan het begin, bla bla is geen RSA1 key, ik heb gewoon ssh-keygen gedraaid, alles enter (default) en een wachtwoord ingetypt 2x.

Die meldingen heb ik ook gewoon. Niets om je zorgen over te maken.
Waar ik me wel zorgen over maak is dat jij blijkbaar twee private keys hebt gemaakt: een RSA en een DSA (id_dsa). Geef nou eens (voor de zoveelste keer) op de command line de juiste mee: '-i ~/.ssh/id_rsa'. (de *private* key, niet de public key!)

-i identity_file
             Selects a file from which the identity ([b][u]private[/u][/b] key) for RSA or
             DSA authentication is read.

Verder slaagt de auth niet omdat de private key die je client gebruikt niet hoort bij een van de public keys, voor zover ik nu kan zien uit de output.

Nogmaals: post ook de output van de server als je inlogt.

My guess: je haalt het allemaal een beetje door elkaar, maakt slordige foutjes ergens of je loopt tegen bugs aan door het gebruik van bleeding-edge software.

[ Voor 20% gewijzigd door gertvdijk op 14-07-2009 15:33 ]

[Verwijderd]

Het probleem zit duidelijk tussen het beeldscherm en de stoel

Why o why verander je in je /etc/ssh_config, why o why verander je AuthorizedKeysFile regel in je /etc/sshd_config, enzovoort enzovoort

Ik heb het al eerder gezegd je moet alleen de volgende twee regels veranderen voor een redelijk veilige ssh server:

PermitRootLogin no
PasswordAuthentication no

en voor de rest overal met je vingers vanaf blijven.

[John_Glenn]

MoiZie schreef op dinsdag 14 juli 2009 @ 15:04:
Wat ik raar vind is de melding aan het begin, bla bla is geen RSA1 key, ik heb gewoon ssh-keygen gedraaid, alles enter (default) en een wachtwoord ingetypt 2x.

Volgens mij is RSA1 iets uit de tijd van ssh versie 1.zoveel, dus dat is het probleem inderdaad niet.

gertvdijk schreef op dinsdag 14 juli 2009 @ 15:26:
Waar ik me wel zorgen over maak is dat jij blijkbaar twee private keys hebt gemaakt: een RSA en een DSA (id_dsa).

Volgens mij zoekt de ssh client gewoon naar alle standaardnamen, dus ook "identity", en "id_dsa", maar dat daar een -1 bij staat betekent denk ik dat ie niet gevonden is. Heb ik hier ook in mijn output.

Verder slaagt de auth niet omdat de private key die je client gebruikt niet hoort bij een van de public keys, voor zover ik nu kan zien uit de output.

Lijkt me dat dat het gewoon is. Even opnieuw die authorized_keys editen, en permissies checken.

My guess: je haalt het allemaal een beetje door elkaar, maakt slordige foutjes ergens of je loopt tegen bugs aan door het gebruik van bleeding-edge software.

Zo bleeding-edge is die blije Koala ook weer niet. Basale tools als ssh komen gewoon standaard van upstream denk ik. Ik gok op de optie slordige foutjes

@Moizie, deze gast heeft alles aardig op een rijtje als je die keygen nog even door wil nemen: http://sial.org/howto/openssh/publickey-auth/

[gertvdijk]

John_Glenn schreef op dinsdag 14 juli 2009 @ 15:49:
Volgens mij zoekt de ssh client gewoon naar alle standaardnamen, dus ook "identity", en "id_dsa", maar dat daar een -1 bij staat betekent denk ik dat ie niet gevonden is. Heb ik hier ook in mijn output.

Ik heb die niet in mijn output, maar wellicht heb je gelijk, hoor.
Verder is de output pas verschillend vanaf regel 115, daar krijg ik wel reactie van de server.

John_Glenn schreef op dinsdag 14 juli 2009 @ 15:49:
Zo bleeding-edge is die blije Koala ook weer niet. Basale tools als ssh komen gewoon standaard van upstream denk ik.

Mwa, een bugje in ssh-keygen kan wellicht lang onopgemerkt blijven, omdat mensen niet dagelijks keys lopen te maken.

John_Glenn schreef op dinsdag 14 juli 2009 @ 15:49:
Ik gok op de optie slordige foutjes

Ik ook, maar zie ook de fouten die hij eerder kreeg op de server. Dat duidt wel heel sterk in de richting van bugs.

[John_Glenn]

gertvdijk schreef op dinsdag 14 juli 2009 @ 16:00:
Ik ook, maar zie ook de fouten die hij eerder kreeg op de server. Dat duidt wel heel sterk in de richting van bugs.

Ja, dat bugreport waar je eerder naar linkte is eigenlijk wel een goeie - lijkt erop dat het probleem daar in het passphrase-management door Seahorse zit (alleen is dat zo te zien alleen van toepassing op 9.10, niet 9.04...).

MoiZie: je dus zou voordat je de login doet even "ssh-add -t 100" kunnen typen, en dan je passphrase geven (dwz "onthou de passphrase 100 seconden"). Daarna proberen in te loggen. Dit omzeilt dus de mogelijke bug in Seahorse...

[MoiZie]

gertvdijk schreef op dinsdag 14 juli 2009 @ 15:26:
[...]

Die meldingen heb ik ook gewoon. Niets om je zorgen over te maken.
Waar ik me wel zorgen over maak is dat jij blijkbaar twee private keys hebt gemaakt: een RSA en een DSA (id_dsa). Geef nou eens (voor de zoveelste keer) op de command line de juiste mee: '-i ~/.ssh/id_rsa'. (de *private* key, niet de public key!)

-i identity_file
             Selects a file from which the identity ([b][u]private[/u][/b] key) for RSA or
             DSA authentication is read.

Gedaan, ik had inderdaad de .pub neergezet net, en had de id_rsa moeten gebruiken. Ik heb geen DSA key gemaakt, er bestaat geen id_dsa file, en ssh-keygen maakt standaard alleen een RSA key.

Verder slaagt de auth niet omdat de private key die je client gebruikt niet hoort bij een van de public keys, voor zover ik nu kan zien uit de output.

Tjah, dan moet het bijna wel een bug zijn, ik heb op beide clients meerdere keren de keys weggegooid en opnieuw aangemaakt, waarna ik ze weer gekopieerd heb naar authorized_hosts, en ik ga echt geen tekst veranderen in die public keys / private keys.

Nogmaals: post ook de output van de server als je inlogt.

My guess: je haalt het allemaal een beetje door elkaar, maakt slordige foutjes ergens of je loopt tegen bugs aan door het gebruik van bleeding-edge software.

Ahjah, de output van de server!
/var/log/auth.log geeft dit:

code:

Jul 14 16:24:39 Adrastea sshd[31514]: Authentication refused: bad ownership or modes for directory /home/moizie
Jul 14 16:24:39 Adrastea sshd[31514]: Authentication refused: bad ownership or modes for directory /home/moizie
Jul 14 16:24:44 Adrastea sshd[31514]: Accepted password for moizie from ] port 16681 ssh2

Imho een erg curieuze melding, aangezien ik inmiddels wel 10x een chmod 700 .ssh/ en chmod 600 .ssh/* heb gedaan.

Ik heb het dus nogmaals gedaan

moizie@Adrastea:~$ chmod 700 .ssh/
moizie@Adrastea:~$ chmod 600 .ssh/*

En weer geprobeerd in te loggen (andere terminal, zelfde client), maar weer password login. moizie:moizie is owner van de map .ssh en alle bestanden daarin.

Verwijderd schreef op dinsdag 14 juli 2009 @ 15:48:
Het probleem zit duidelijk tussen het beeldscherm en de stoel

Dank je .

Why o why verander je in je /etc/ssh_config, why o why verander je AuthorizedKeysFile regel in je /etc/sshd_config, enzovoort enzovoort

Ik heb het al eerder gezegd je moet alleen de volgende twee regels veranderen voor een redelijk veilige ssh server:

PermitRootLogin no
PasswordAuthentication no

en voor de rest overal met je vingers vanaf blijven.

En dan werkt het niet, zoals ik dus al heb gezegd eerder, ik heb nu ssh opnieuw geinstalleerd (purge, install). Dan staat PublickeyAuthentication op no, en uitgecomment! Dus als ik alleen verander wat jij zegt, kan ik de server niet benaderen. PermitRootLogin staat ook standaard al op no. Dat is allemaal default config! Verander ik niets aan! Dus ik haal het hekje bij PublickeyAuthentication weg en verander de no in yes, de rest is default, of later weggecomment omdat het toch niet werkt.

John_Glenn schreef op dinsdag 14 juli 2009 @ 16:12:
[...]


Ja, dat bugreport waar je eerder naar linkte is eigenlijk wel een goeie - lijkt erop dat het probleem daar in het passphrase-management door Seahorse zit (alleen is dat zo te zien alleen van toepassing op 9.10, niet 9.04...).

MoiZie: je dus zou voordat je de login doet even "ssh-add -t 100" kunnen typen, en dan je passphrase geven (dwz "onthou de passphrase 100 seconden"). Daarna proberen in te loggen. Dit omzeilt dus de mogelijke bug in Seahorse...

moizie@Rhea:/media/mylibrary/Downloads$ ssh-add -t 100
Enter passphrase for /home/moizie/.ssh/id_rsa:
Identity added: /home/moizie/.ssh/id_rsa (/home/moizie/.ssh/id_rsa)
Lifetime set to 100 seconds
moizie@Rhea:/media/mylibrary/Downloads$ ssh host
moizie@Server password:

Helaas dus, maar leuk bedacht .

[ Voor 12% gewijzigd door MoiZie op 14-07-2009 16:32 ]

[gertvdijk]

MoiZie schreef op dinsdag 14 juli 2009 @ 16:30:
[...]

Authentication refused: bad ownership or modes for [u][b]directory /home/moizie[/b][/u]

[...]

Imho een erg curieuze melding, aangezien ik inmiddels wel 10x een chmod 700 .ssh/ en chmod 600 .ssh/* heb gedaan.

Stap 1: LEZEN! En als je het nog niet snapt, ga dan terug naar stap 1.
Ik mag hopen dat er nu een 'OOOH JA!' momentje komt.
Hint (manpage sshd_config):

     [b]StrictModes[/b]
             Specifies whether sshd(8\) should check file modes and ownership
             of the user’s files and home directory before accepting login.
             This is normally desirable because novices sometimes accidentally
             leave their directory or files world-writable.  The default is
             “yes”.

en uit de manpage sshd

             If this file, the ~/.ssh directory, or the user’s home directory
             are writable by other users, then the file could be modified or
             replaced by unauthorized users.  In this case, sshd will not
             allow it to be used unless the StrictModes option has been set to
             “no”.  The recommended permissions can be set by executing “chmod
             go-w ~/ ~/.ssh ~/.ssh/authorized_keys”.

Oftewel geef eens de output van

ls -alR /home/moizie/.ssh

(op de server natuurlijk)
Alleen snap ik dan nog niet waarom je wel met een password in kan loggen.

[ Voor 62% gewijzigd door gertvdijk op 14-07-2009 16:45 ]

[MoiZie]

moizie@Adrastea:/home$ ls -alR /home/moizie/.ssh
/home/moizie/.ssh:
total 24
drwx------ 2 moizie moizie 4096 2009-07-13 20:56 .
drwxr-xr-x 57 moizie moizie 4096 2009-07-12 23:13 ..
-rw------- 1 moizie moizie 786 2009-07-14 16:36 authorized_keys
-rw------- 1 moizie moizie 1743 2009-07-09 20:04 id_rsa
-rw------- 1 moizie moizie 397 2009-07-09 20:04 id_rsa.pub
-rw------- 1 moizie moizie 1768 2009-06-20 15:50 known_hosts


Dat dus. Weirder: Ik probeer nu tussen de 2 clients ook een ssh verbinding met pubkey aan te zetten, maar ook die failen en gaan terug naar passwordauthentication. Zowel A --> B als B --> A dus.

edit: snel editten he? chmod go-w ~/ ~/.ssh ~/.ssh/authorized_keys zorg voor een verandering in bovenstaand, van drwxrwxrwx op de .. naar drwxr-xr-x En die verandering zorgt ervoor dat ik in kan loggen met de passphrase!

edit2: Datzelfde toepassen op de jaunty client zorgt ervoor dat ook naar die client met passphrase geconnect kan worden (getest vanaf de karmic client), maar met de karmic client kan nog steeds geen verbinding gemaakt worden.

edit3: Maar wel na een sudo chown moizie:moizie op de directory, .ssh/authorized_keys was opeens van root:root namelijk!

Wow! Ik kan nu overal vandaan connecten! Ik heb het commando chmod go-w ~/ al eerder uitgevoerd, zoals de openssh keys help al had gezegd, maar pas nadat ik ~/.ssh ~/.ssh/authorized_keys erachter had gezet werkte het kennelijk echt!

[ Voor 43% gewijzigd door MoiZie op 14-07-2009 16:59 ]

[gertvdijk]

MoiZie schreef op dinsdag 14 juli 2009 @ 16:47:
moizie@Adrastea:/home$ ls -alR /home/moizie/.ssh
/home/moizie/.ssh:
total 24
drwx------ 2 moizie moizie 4096 2009-07-13 20:56 .
drwxr-xr-x 57 moizie moizie 4096 2009-07-12 23:13 ..
-rw------- 1 moizie moizie 786 2009-07-14 16:36 authorized_keys
-rw------- 1 moizie moizie 1743 2009-07-09 20:04 id_rsa
-rw------- 1 moizie moizie 397 2009-07-09 20:04 id_rsa.pub
-rw------- 1 moizie moizie 1768 2009-06-20 15:50 known_hosts

Oke ziet er goed uit (mits Adrastea je server is), dus je hebt ook weer (andere) keys staan op je server? Het wordt er zo niet overzichtelijker op...
Bonustip: maak je homedir niet world-readable...

MoiZie schreef op dinsdag 14 juli 2009 @ 16:47:
Dat dus. Weirder: Ik probeer nu tussen de 2 clients ook een ssh verbinding met pubkey aan te zetten, maar ook die failen en gaan terug naar passwordauthentication. Zowel A --> B als B --> A dus.

Doe je toch echt iets structureels fout. Ik kan je vertellen dat de rest van de wereld er geen problemen mee heeft, of sterker nog, er sterk op leunt.

MoiZie schreef op dinsdag 14 juli 2009 @ 16:47:
edit: snel editten he? chmod go-w ~/ ~/.ssh ~/.ssh/authorized_keys zorg voor een verandering in bovenstaand, van drwxrwxrwx op de .. naar drwxr-xr-x

Ik voeg alleen dingen uit de manpage.
Hoe bedoel je 'zorgt voor een verandering is bovenstaand'? Dus je had eerst je homedir wel world-writeable?

Na je tweede edit: Tja, welke malloot heeft zijn homedir op 777 staan. Exact iets waar sshd je op wees...
Ik zou eens uitzoeken waarom je homedir op die mode stond. Maar ik gok dat de oorzaak ook weer tussen de stoel en het scherm zit... Leer eens goed configureren, joh.

Na je derde edit: Je wist dus niet waar je mee bezig was, je checkte dingen niet of je was onvolledig... tja, leermomentje.

[ Voor 10% gewijzigd door gertvdijk op 14-07-2009 17:01 ]

[MoiZie]

gertvdijk schreef op dinsdag 14 juli 2009 @ 16:57:
Hoe bedoel je 'zorgt voor een verandering is bovenstaand'? Dus je had eerst je homedir wel world-writeable?

Na je tweede edit: Tja, welke malloot heeft zijn homedir op 777 staan. Exact iets waar sshd je op wees...

Het is een standaard ubuntu server install... Ik heb nooit een chmod -R 777 /home/moizie gedaan of zo..

[gertvdijk]

MoiZie schreef op dinsdag 14 juli 2009 @ 17:00:
Het is een standaard ubuntu server install... Ik heb nooit een chmod -R 777 /home/moizie gedaan of zo..

Dan zou ik maar eens uitzoeken hoe dat komt. Niemand wil zijn homedir 777 hebben staan.

Jouw lessen zijn duidelijk:

• Logs lezen
• Logs goed lezen
• Logs nog een keer goed lezen
• Dubbelchecken of je wel precies doet wat je moet doen.
• Niet meer doen dan nodig is.
• Rustig blijven.

[ Voor 27% gewijzigd door gertvdijk op 14-07-2009 17:06 ]

[MoiZie]

gertvdijk schreef op dinsdag 14 juli 2009 @ 17:02:
[...]

Dan zou ik maar eens uitzoeken hoe dat komt. Niemand wil zijn homedir 777 hebben staan.

Noujah, dat staat hij nu ook niet meer Misschien komt het door Samba? Ik weet nu niet of dat nog werkt (zit niet op dat netwerk), maar ik weet wel dat ik geprobeerd heb om mijn /home te sharen, voor alleen mijzelf.

Anyway, dit probleem is opgelost, passwordauthentication staat uit en ik draai nu op een niet standaard port. Voel me veilig . Dank allen voor de hulp .

edit: Rustig blijven.. Jah.. ik stress te snel en dan denk ik niet meer logisch na. Genetisch foutje Wat hieraan ook niet heeft bijgedragen is het sshd_config / ssh_config gebeuren.. Waarom 2 bestanden die volgens mij bijna hetzelfde doen..

[ Voor 17% gewijzigd door MoiZie op 14-07-2009 17:10 ]

[gertvdijk]

MoiZie schreef op dinsdag 14 juli 2009 @ 17:07:
edit: Rustig blijven.. Jah.. ik stress te snel en dan denk ik niet meer logisch na. Genetisch foutje

Bonustip
file@client ~/.ssh/config

code:

host server
port 1234
hostname 123.45.67.89

zodat verbinden verkort wordt tot 'ssh server'.

[Verwijderd]

MoiZie schreef op dinsdag 14 juli 2009 @ 17:07:
[...]
Waarom 2 bestanden die volgens mij bijna hetzelfde doen..

Nee, die bestanden doen echt twee heel verschillende dingen:

ssh_config - OpenSSH SSH client configuration files

sshd_config - OpenSSH SSH daemon configuration file

@Gert misschien moeten we maar eens het Grote OpenSSH topic beginnen

[gertvdijk]

Verwijderd schreef op dinsdag 14 juli 2009 @ 17:24:
@Gert misschien moeten we maar eens het Grote OpenSSH topic beginnen

Ja, misschien is dat wel een goed idee. Vol met tips over hoe je eenvoudig en veilig kan SSH'en.
Grote uitdaging is dan wel om voor lezers die je moet wijzen op het niet zo subtiele verschil tussen client en daemon (zucht - nofi) foolproof how-to's in de TS te maken.

MoiZie schreef op dinsdag 14 juli 2009 @ 17:07:
Waarom 2 bestanden die volgens mij bijna hetzelfde doen..

Nog een bonustip: typ eens in een terminal 'man' voor alles waarvan je niet weet wat het doet of is, druk op enter en start reading.

[ Voor 46% gewijzigd door gertvdijk op 14-07-2009 17:35 ]

[Boudewijn]

MoiZie schreef op dinsdag 14 juli 2009 @ 17:07:

edit: Rustig blijven.. Jah.. ik stress te snel en dan denk ik niet meer logisch na. Genetisch foutje Wat hieraan ook niet heeft bijgedragen is het sshd_config / ssh_config gebeuren.. Waarom 2 bestanden die volgens mij bijna hetzelfde doen..

De ene heeft een d erin staan.
Zou iets te maken kunnen hebben met daemon?

En het andere is dan voor de client? (shit, er zit logica in)

[Verwijderd]

gertvdijk schreef op dinsdag 14 juli 2009 @ 17:30:
[...]

Ja, misschien is dat wel een goed idee. Vol met tips over hoe je eenvoudig en veilig kan SSH'en.
Grote uitdaging is dan wel om voor lezers die je moet wijzen op het niet zo subtiele verschil tussen client en daemon (zucht - nofi) foolproof how-to's in de TS te maken.

Ik zit alleen met mijn "Het Grote Music Player Daemon Topic", ik kan moeilijk daarnaast nog eens "Het Grote OpenSSH Topic" starten, de moderators zien me al aankomen Maar ik denk zelf wel dat een groot OpenSSH topic het heel goed zou doen

[MoiZie]

Boudewijn schreef op dinsdag 14 juli 2009 @ 17:40:
[...]

De ene heeft een d erin staan.
Zou iets te maken kunnen hebben met daemon?

En het andere is dan voor de client? (shit, er zit logica in)

Ja, het is logisch, ik weet het. Maar tegelijk ook verwarrend. Ik verwacht niet op die plek een config file voor de client, /etc is voor mij een plek waar alle services staan, apache, ssh, etcetera.. Misschien heb ik dat ook wel fout, maar als overstappend windows gebruiker heb ik die indruk. Dan is er ook een plek genaamd /var en /home, waarbij ik daar ergens de client configuratie verwacht.. Niet in dezelfde directory. Voor jullie als ervaren nix gebruikers is het misschien heel logisch, maar (zeker in het begin, ik werk er nu zo'n half jaar mee) voor mij niet .

[gertvdijk]

MoiZie schreef op dinsdag 14 juli 2009 @ 18:25:
Ja, het is logisch, ik weet het. Maar tegelijk ook verwarrend. Ik verwacht niet op die plek een config file voor de client, /etc is voor mij een plek waar alle services staan, apache, ssh, etcetera..

Tot zover klopt dit helemaal.

MoiZie schreef op dinsdag 14 juli 2009 @ 18:25:
Dan is er ook een plek genaamd /var en /home, waarbij ik daar ergens de client configuratie verwacht..

Wat ik al de hele tijd roep: zet je client config in ~/.ssh/config
En daarnaast: /var is er niet voor configs, en al helemaal niet voor user-specific dingen.

[MoiZie]

gertvdijk schreef op dinsdag 14 juli 2009 @ 18:50:
[...]

Tot zover klopt dit helemaal.

[...]

Wat ik al de hele tijd roep: zet je client config in ~/.ssh/config
En daarnaast: /var is er niet voor configs, en al helemaal niet voor user-specific dingen.

Ok... maar waarom staat een hele website dan wel in /var/www? Meer user-specifiek kan je niet gaan toch? Iemand wil een website draaien, en daar moeten de bestanden in.. En ik weet dat je dat roept, maar in het /etc/ssh/ssh_config bestand staat ook dat hij als laatste kijkt naar het system-wide geval, en aangezien ik de 'enige' user ben, wil ik alles system-wide houden, zodat ik weet waar ik moet zoeken op google, wat op mij van toepassing is dus.

[gertvdijk]

MoiZie schreef op dinsdag 14 juli 2009 @ 18:53:
Ok... maar waarom staat een hele website dan wel in /var/www? Meer user-specifiek kan je niet gaan toch?

Euhm... Niet iedereen heeft een hostingbedrijf met allemaal untrusted users... Redelijk offtopic dit, maar oke.
Een website voor iedere user hoort in zijn eigen homedir. Die functionaliteit zit in mod_userdir voor Apache en webserver config kan je laten doen d.m.v. htaccess file.

MoiZie schreef op dinsdag 14 juli 2009 @ 18:53:
En ik weet dat je dat roept, maar in het /etc/ssh/ssh_config bestand staat ook dat hij als laatste kijkt naar het system-wide geval

Ja, want user-specific dingen gaan altijd boven system-wide.

MoiZie schreef op dinsdag 14 juli 2009 @ 18:53:
en aangezien ik de 'enige' user ben, wil ik alles system-wide houden, zodat ik weet waar ik moet zoeken op google, wat op mij van toepassing is dus.

Ach als jij single-user wil spelen in een multi-user OS dan maak je het jezelf alleen maar moeilijker, minder-veilig en krijg je onverwachte problemen. Ik mag hopen dat Google je ook voornamelijk stuurt naar het hebben van een SSH *client* config in je homedir. Die vlieger/excuus daaromtrent slaat echt kant nog wal...

Je kan je beter verdiepen in hoe de rest van de wereld dingen aanpakt dan in je eigen wereldje je eigen logica strijdig te moeten verklaren met het gedrag van je systeem.

[ Voor 5% gewijzigd door gertvdijk op 14-07-2009 19:03 ]

[MoiZie]

gertvdijk schreef op dinsdag 14 juli 2009 @ 19:01:
Je kan je beter verdiepen in hoe de rest van de wereld dingen aanpakt dan in je eigen wereldje je eigen logica strijdig te moeten verklaren met het gedrag van je systeem.

Een les die ik vandaag geleerd heb. Ik voel me dan ook nog lang niet zo ervaren met Ubuntu als ik mij met Windows voel, wat weer heel anders is (alle configuratie-opties van een programma, staan samen met de libraries en de executable in 1 map). Ach, gezien ik hier pas een half jaar mee bezig ben, en Windows voor mij zo'n 8 jaar oud is, is het verschil ook logisch. Toch snap ik wel waarom mensen niet graag overstappen.

[gertvdijk]

MoiZie schreef op dinsdag 14 juli 2009 @ 19:14:
Een les die ik vandaag geleerd heb. Ik voel me dan ook nog lang niet zo ervaren met Ubuntu als ik mij met Windows voel, wat weer heel anders is (alle configuratie-opties van een programma, staan samen met de libraries en de executable in 1 map). Ach, gezien ik hier pas een half jaar mee bezig ben, en Windows voor mij zo'n 8 jaar oud is, is het verschil ook logisch. Toch snap ik wel waarom mensen niet graag overstappen.

Lol, ja. Wat ook veel mensen vergeten is hun Windows-mindset en -referentiekader uit het raam te gooien voor ze overstappen en het al gauw niet goed vinden puur omdat het anders werkt dan in Windows. Ik denk dat het centrale package management t.o.v. download.com daarvan nog wel het beste voorbeeld is.

[Verwijderd]

@MoiZie dit is wel leuk om te lezen dat maakt veel dingen duidelijker:

http://linux.oneandoneis2.org/LNW.htm

[MoiZie]

Haha, zeker grappig, ook heel herkenbaar als ik een paar reacties lees. Zo vastgegroeid zijn in de windows-way-of-life dat je alles op die manier vergelijkt en benadert. Toch vind ik dat ik (met de nodige, opgeloste, problemen) al vrij ver ben gekomen.