Moeilijk Linux SSH Probleem

[Verwijderd]

Ik heb samen met nog een Linux Expert gekeken naar een SSH probleem.
Ik heb een Applicatie server waar ik de progs vandaan roep met ssh -X
Maar ik kan niet verbinden.
Aangezien het password loos moet zijn is dat een probleem..

Ik krijg als ik vanaf de Client naar de Server ga met het command:
ssh -2 -c blowfish -X user_at_appserver@appserversip

Moet ik een Wachtword in voeren.
Dat wachtwoord kan helemaal niks zijn
wat ik heb passwordless gedaan.


Het is een Gentoo box.
Ik heb dus de tutorial http://gentoo-wiki.com/SECURITY_SSH_without_a_password gevolgt.
En heb de vraag ook:
http://www.linuxforums.or...dless-ssh.html#post537478
http://forums.gentoo.org/viewtopic-p-4615952.html#4615952
http://www.linuxforums.or...ter-reboot-sshd-dead.html

Ik weet niet zeker of iemand meer informatie nodig heeft.

Kan iemand mij PLEASE helpen.

Groet,
Robin

[lintweaker]

Verwijderd schreef op vrijdag 14 december 2007 @ 12:59:
Ik heb samen met nog een Linux Expert gekeken naar een SSH probleem.
Ik heb een Applicatie server waar ik de progs vandaan roep met ssh -X
Maar ik kan niet verbinden.
Aangezien het password loos moet zijn is dat een probleem..

Ik krijg als ik vanaf de Client naar de Server ga met het command:
ssh -2 -c blowfish -X user_at_appserver@appserversip

Moet ik een Wachtword in voeren.
Dat wachtwoord kan helemaal niks zijn
wat ik heb passwordless gedaan.


Het is een Gentoo box.
Ik heb dus de tutorial http://gentoo-wiki.com/SECURITY_SSH_without_a_password gevolgt.
En heb de vraag ook:
http://www.linuxforums.or...dless-ssh.html#post537478
http://forums.gentoo.org/viewtopic-p-4615952.html#4615952
http://www.linuxforums.or...ter-reboot-sshd-dead.html

Ik weet niet zeker of iemand meer informatie nodig heeft.

Kan iemand mij PLEASE helpen.

Groet,
Robin

Een tijdje geleden heb ik ook zoiets opgezet. Volgens mij moet je altijd een eerste keer je password geven om de key vrij te geven (of iets dergelijks). Als je ssh-agent draait kun je na 1 keer ingeven password wel verder inloggen op alle machines waarop je de keys hebt gezet.

Hoop dat dit je wat helpt.

[Verwijderd]

Een tijdje geleden heb ik ook zoiets opgezet. Volgens mij moet je altijd een eerste keer je password geven om de key vrij te geven (of iets dergelijks). Als je ssh-agent draait kun je na 1 keer ingeven password wel verder inloggen op alle machines waarop je de keys hebt gezet.

Hoop dat dit je wat helpt.

Nope... wanneer je die howto goed gevolgd heb zou dat gewoon moeten werken... Je hoeft dan niet je password een keer in te voeren om een sleutel te accepteren... aangezien je de sleutel al hebt, die heb je lokaal moeten zetten in ~/.ssh/

Ik heb de howto eens bekeken en dat is een prima howto... Zou gewoon moeten werken.

Het enige wat je ff kan proberen is op de server is ~/.ssh/authorized_keys ff renamen naar ~/.ssh/authorized_keys2

Check je sshd_config op de server hoe die file precies moet heten... Meestal is het dus authorized_keys of authorized_keys2

Anders ff verbose mode aanzetten, dan zie je misschien wat er fout gaat, inloggen dus met: ssh -v

[ Voor 4% gewijzigd door Verwijderd op 14-12-2007 13:33 ]

[berties]

Met welke user run je het commando ssh op de locale server? Is dit gelijk aan user_at_appserver ?

[Verwijderd]

[b][message=29260640,noline]Grumpy-Tux schreef op vrijdag 14 december 2007 @
Het is een Gentoo box.
...

Wat staat er allemaal in de log files van sshd? Het ligt er aan hoe jou configuratie er uit ziet, maar meestal staan de log files van sshd in /var/log/auth.log

[BCC]

Heb je niet toevallig keys gemaakt met een passphrase? Dan vraagt hij daar nl. om voordat hij de key mag/kan gebruiken.

Ik heb gisteren nog een server passwordless gemaakt, het hoort echt geen rocket science te zijn.

[ Voor 66% gewijzigd door BCC op 14-12-2007 13:59 ]

[daft_dutch]

ik vind dit wel raar. als er iemand met een linux expert naar kijkt.
A omdat -2 en de -c optie weg gelaten kan worden de client en server komen draar prima zelf uit.
2 Men niet zonder paswoord gecontroleerd heeft.

een password loze key is gemaakt in een hand omdraai.
misschien heb je de private/public keys op de verkeerde pc gezet.

[Verwijderd]

Nou hij werkte eerst ook.
Maar toen was hij er opeens mee opgehouden. Na wat klieren van Config files. (dns uitzetten dat soort dingen) en een Update.
Daarna deed hij niks meer.
De server heeft de volgende bestanden in de /etc/ssh folder staan:

moduli
ssh_config
ssh_hosts_dsa_key
ssh_hosts_dsa_key.pub
ssh_host_key
ssh_host_key.pub
ssh_host_rsa_key
ssh_host_rsa_key.pub
ssh_prng_cmds
sshd_config <- Dat is de daemon dus die is belangrijk voor de server.

De inhoud van dat bestand is:

# $OpenBSD: sshd_config,v 1.74 2006/07/19 13:07:10 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
#AddressFamily any
#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 no
#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 yes
# similar for protocol version 2
HostbasedAuthentication yes
# 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 no
#I chaned the above from yes to no
#PermitEmptyPasswords no

# Change to no to disable s/key passwords
ChallengeResponseAuthentication no
# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

# 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
UsePAM yes

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

# no default banner path
#Banner /some/path

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

# Example of overriding settings on a per-user basis
#Match User anoncvs
X11Forwarding yes
# AllowTcpForwarding no
# ForceCommand cvs server

Als ik probeer te verbinden met -vv als verbose krijg ik:
[quote]
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host '192.168.1.1' is known and matches the RSA host key.
debug1: Found key in /home/john/.ssh/known_hosts:1
debug2: bits set: 516/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/john/.ssh/id_dsa.pub (0x809bb68)
debug1: Authentications that can continue: publickey,hostbased
debug1: Next authentication method: publickey
debug1: Offering public key: /home/john/.ssh/id_dsa.pub
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-dss blen 434
debug2: input_userauth_pk_ok: fp 8d:7a:a8:c9:a5:25:e8:e6:0c:7b:a5:b9:43:da:23:49
debug1: PEM_read_PrivateKey failed
debug1: read PEM private key done: type <unknown>
Enter passphrase for key '/home/john/.ssh/id_dsa.pub':
[/qoute]

Zo als je ziet kan hij de private key niet lezen (zegt hij)
dus ik check de rechten.
En die zijn: 500 (op id_dsa.pub)
dus ik dacht dan geef ik lees rechten aan Group of World.
Dus ik probeer de volgende rechten:
540
504
544
En ik krijg steeds:
[quote]
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: UNPROTECTED PRIVATE KEY FILE! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0504 for '/home/john/.ssh/id_dsa.pub' are too open.
It is recommended that your private key files are NOT accessible by others.
This private key will be ignored.
bad permissions: ignore key: /home/john/.ssh/id_dsa.pub
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey,hostbased).
[/qoute]

Dus, mja kan iemand helpen?

Cheers,
Robin

[Verwijderd]

Verwijderd schreef op vrijdag 14 december 2007 @ 13:55:
[...]
maar meestal staan de log files van sshd in /var/log/auth.log

Er staat helemaal niks dat er op lijkt.
Mijn log dir heeft:
cups/ emerge.log news/ sandbox/
dmesg lastlog portage/ wtmp

Dus mja..

Cheers,
Robin

[GX]

Verwijderd schreef op maandag 17 december 2007 @ 09:16:
Nou hij werkte eerst ook.
Maar toen was hij er opeens mee opgehouden. Na wat klieren van Config files. (dns uitzetten dat soort dingen) en een Update.
Daarna deed hij niks meer.
De server heeft de volgende bestanden in de /etc/ssh folder staan:

[...]

De inhoud van dat bestand is:

[...]

Als ik probeer te verbinden met -vv als verbose krijg ik:
[...]

Zo als je ziet kan hij de private key niet lezen (zegt hij)
dus ik check de rechten.
En die zijn: 500 (op id_dsa.pub)
dus ik dacht dan geef ik lees rechten aan Group of World.
Dus ik probeer de volgende rechten:
540
504
544
En ik krijg steeds:

[...]

Dus, mja kan iemand helpen?

Cheers,
Robin

Hij zegt helemaal niet dat hij het bestand niet kan lezen, hij vraagt om je passphrase, zoals al eerder vermeld. Je moet gewoon je key genereren zonder een passphrase en dan werkt het, ook zoals eerder gemeld.

En die unprotected keyfile komtt omdat je permissies te open staan, staat er ook gewoon bij, overigens.

Misschien ga je verder komen in de oplossing, als je ook daadwerkelijk leest wat er staat.

[ Voor 23% gewijzigd door GX op 17-12-2007 09:44 ]

[Verwijderd]

Hij heeft GEEN key-phrase!
Ik heb op ENTER gedrukt daar.
Dus ik heb wel degelijk gelezen wat dat daar staat.

[frapex]

Verwijderd schreef op maandag 17 december 2007 @ 09:16:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: UNPROTECTED PRIVATE KEY FILE! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0504 for '/home/john/.ssh/id_dsa.pub' are too open.
It is recommended that your private key files are NOT accessible by others.
This private key will be ignored.
bad permissions: ignore key: /home/john/.ssh/id_dsa.pub
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey,hostbased).

Probeer de permissies eens goed te zetten. Hij ignored de private key.

[GX]

Als er geen passphrase is, vraagt hij er ook niet om. Waarom genereer je je key niet gewoon opnieuw en probeer je het nog een keer? Ik maak die dingen met grote regelmaat en toch heb ik nooit een nieuw passphrase in hoeven vullen bij verbinden.

Het enige verschil is dat ik altijd RSA keys maak en bij mij RSAAuthentication staat aan in sshd_config, maar dat is voor ssh1.

[Zwerver]

Verwijderd schreef op maandag 17 december 2007 @ 09:45:
Hij heeft GEEN key-phrase!
Ik heb op ENTER gedrukt daar.
Dus ik heb wel degelijk gelezen wat dat daar staat.

De logmelding zegt toch wat anders, die zegt dat er een passphrase op de public key staat, iets wat me hoogst onwaarschijnlijk lijkt.... Volg anders eens heel exact wat ik hier geschreven heb? Daarbij moet je echt lezen wat er staat, die melding over

WARNING: UNPROTECTED PRIVATE KEY FILE

is ook een logische melding want je beschermt je eigen private key niet meer......

[Verwijderd]

Ik heb al een paar keer een key gegenereerd.
Nou ik heb het weer gedaan op de volgende manier:

Client: ssh-keygen -t dsa
Als hij vraagt om een KeyPraze ram ik op <Enter> en dan moet ik hem nog ens geven dus weer <Enter>..

Ok, all goed.
Dan copy ik de file naar autorize_keys.
No problems..

En dan probeer ik de verbinden krijg ik..

Warning: Permanently added '192.168.1.1' (RSA) to the list of known hosts.
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/john/.ssh/id_dsa.pub (0x809bb68)
debug1: Authentications that can continue: publickey,hostbased
debug1: Next authentication method: publickey
debug1: Offering public key: /home/john/.ssh/id_dsa.pub
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,hostbased
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey,hostbased).

En ik snap dat hij ging zeuren dat hij niet veilig was..

Weer geen verbinding..

[GX]

Dan copy ik de file naar autorize_keys.

Dat is ook de verkeerde filename. En je moet de inhoud van je .pub in authorised_keys zetten, geen file kopieren.

[Verwijderd]

Woops dat is mijn fout. De naam is wel goed.
En ik heb de info gestored.. Dus hij zou gewoon moeten werken..

[Zwerver]

Verwijderd schreef op maandag 17 december 2007 @ 10:34:
Ik heb al een paar keer een key gegenereerd.
Nou ik heb het weer gedaan op de volgende manier:

Client: ssh-keygen -t dsa
Als hij vraagt om een KeyPraze ram ik op <Enter> en dan moet ik hem nog ens geven dus weer <Enter>..

Ok, all goed.
Dan copy ik de file naar autorize_keys.
No problems..

En dan probeer ik de verbinden krijg ik..

[...]


En ik snap dat hij ging zeuren dat hij niet veilig was..

Weer geen verbinding..

En als je nu gewoon eens stap-voor-stap dat stappen plan uitvoert heb je het welkom. Je kan het nota bene C&P-en

[Verwijderd]

Problem Fixes.
For some reason it sends the Private Key over the Inet to the Server instead of the Public one.
I did nothing wrong it was a Common Problem..

[Zwerver]

Verwijderd schreef op dinsdag 18 december 2007 @ 09:22:
Problem Fixes.
For some reason it sends the Private Key over the Inet to the Server instead of the Public one.
I did nothing wrong it was a Common Problem..

O ja joh? Zo common dat er nog niemand in dit topic het tegengekomen is Daarbij is het verzenden van de private-key over internet toch wel heel erg fout, en het lijkt me niet dat het een bug in openssh is. Als dat wel zo is mag je me de link sturen waar je dat gevonden hebt (ojah, doe ook even de link naar het verhaal waar jij uit opmaakt dat het een common problem is)...

offtopic:
De voertaal is Nederlands hier op het forum!

[Verwijderd]

offtopic:
En blijf van die shift knop af...

[Verwijderd]

You should offer the private part of your key!
I think you have things mixed up with SSH keys. But you're not the first, and you won't be the last
Put your public key part on the server in /home/john/.ssh/authorized_keys; and connect with your private key part on the client:

Thats Common.

And I found it on the Gentoo Forums..

[DiedX]

en volledig offtopic:

tail -f /var/log/messages

doet vaak wonderen (ook bij Linux Experts!)

[Verwijderd]

Tjah, toch wel een domme fout, maar echt niet common ofzo. Dat meer mensen die fout maken wil niet zeggen dat het common is.

Als je niet eens fatsoenlijk Engels kunt waarom zit je het hier dan te posten?

[Zwerver]

Verwijderd schreef op dinsdag 18 december 2007 @ 09:38:
[...]


Thats Common.

And I found it on the Gentoo Forums..

Het is een blunder en zeker niet common. Nummer 1 regel tijdens het gerbuik van Public/Private-key-gebruik is dat je de private key nooit mag vrijgeven.

[Verwijderd]

Als jij gewoon ff je kop houd man idioot. @ TRRoads
Dat is Prima engels. De helft van mijn Family is Engels
Verder dat tail -f /var/log/messages heb ik gedaan maar er werd niks gezien.
Jezus waarom kunnen jullie mensen niet in de waarde laten.
Echt serieus jullie zijn echt verveelend volk.

[ Voor 4% gewijzigd door Verwijderd op 18-12-2007 09:53 ]

[GX]

En daarnaast is het in de howto EN in dit topic al gemeld dat je de .pub in dat bestand moet zetten. Zoals ik eerder heb gezegd, ga lezen voordat je aan het prutsen gaat.

[blaataaps]

Als je opeens geen nederlands meer kan en zo gaat reageren als mensen je proberen te helpen bij je eigen tikfout heeft het ook geen zin meer. En dat je hele "Family" Engels is (waarom gebruik je dan het duitse hoofdlettersysteem?) maakt fout engels niet opeens "Prima Engels".

[zomertje]

Blaataaps was me voor

[ Voor 78% gewijzigd door zomertje op 18-12-2007 09:57 ]