[ssh / putty] no password authentication

[Verwijderd]

[probleem]
Ik heb een aantal servers die ik beheer door middel van SSH via Putty op een Windows laptop. Het probleem is echter dat ik nogal moe wordt van het telkens inloggen met een password (via putty). Echter krijg ik het niet voor elkaar.

[Wat heb ik al gedaan?]
Ik heb met puttygen(.exe) een public en een private key gegeneerd (SSH_RSA en SSH_DSA). Zie afbeelding:



De public key (DSA) heb ik uit puttygen gekopieerd en in ~/.ssh/authorized_keys2 geplakt (En deze public key staat op 1 regel!, dus zonder enters e.d.).

Vervolgens heb ik de private key opgeslagen als tekstbestand in c:\private.PPK

Vervolgens stel ik putty zo in dat hij deze key (private) gebruikt... Zie ook de afbeelding:



Daarnaast stel ik Putty in zodat hij het SSH2 protocol gebruikt. Afbeelding:



Vervolgens als ik connect krijg ik alleen maar:

login as: harm
Sent username "harm"
Trying public key authentication.
No passphrase required.
Server refused our public key.
harm@10.1.0.13's password:

Wat gaat er toch mis? Ik heb het idee dat het iets te maken heeft met een instelling op de server. (Misschien gebruikt mijn ssh-server geen SSH2 protocol?, maar ik weet niet hoe ik dat kan controleren).

[specs]
Redhat Linux 7.3
openssh-3.1p1-6
En Putty voor Windows (stable versie)


Kan iemand mij op weg helpen?

[Creepy]

In het eerste scherm staat "Public key for pasting in Authorized_keys file".

Oftewel: Je hebt op de machine waar de SSH server opdraait aangegeven dat jij met die key kan inloggen??

[ Voor 6% gewijzigd door Creepy op 03-12-2002 14:53 ]

[Verwijderd]

Creepy schreef op 03 December 2002 @ 14:53:
In het eerste scherm staat "Public key for pasting in Authorized_keys file".

Oftewel: Je hebt op de machine waar de SSH server opdraait aangegeven dat jij met die key kan inloggen??

Ja, die heb ik in ~/.ssh/authorized_keys2 geplakt... Zie ook mijn eerste posting:

De public key (DSA) heb ik uit puttygen gekopieerd en in ~/.ssh/authorized_keys2 geplakt (En deze public key staat op 1 regel!, dus zonder enters e.d.).

[jurri@n]

Gezorgd dat de SSH-deamon je files opnieuw ingelezen heeft (b.v. door de deamon opnieuw te starten).

[Verwijderd]

jurri@n schreef op 03 december 2002 @ 15:06:
Gezorgd dat de SSH-deamon je files opnieuw ingelezen heeft (b.v. door de deamon opnieuw te starten).

Hoewel dat volgens mij niets uitmaakt heb ik toch even geprobeerd... Maar zoals ik al vermoedde maakt dat geen enkel verschil....

[Wilke]

Geen antwoord op de vraag, maar misschien handig om 'es door te bladeren:

OpenSSH key management, Part 1 - Understanding RSA/DSA Authentication.

Ik heb het daarmee wel aan de praat gekregen, maar dat was Linux <-> Linux. Hoe het icm Putty moet weet ik niet precies.

[Verwijderd]

Ja, van linux <--> linux werkt het wel... Maar niet van windows <---> Linux.....
Toch bedankt voor de link... Ga het zeker eens bekijken.

[jvhaarst]

Wat zegt de eventlog van putty ? (rechtsklikken op de balk)

[Verwijderd]

Volgens mij moet je nog een passphase opgeven (wachtwoord) zonder deze is ssh niet veilig genoeg en gaat ie proberen om je gewoon in te loggen.

[Verwijderd]

jvhaarst schreef op 03 December 2002 @ 15:24:
Wat zegt de eventlog van putty ? (rechtsklikken op de balk)

code:

2002-12-03 15:28:15 Looking up host "10.1.0.13"
2002-12-03 15:28:15 Connecting to 10.1.0.13 port 22
2002-12-03 15:28:15 Server version: SSH-1.99-OpenSSH_3.1p1
2002-12-03 15:28:15 We claim version: SSH-2.0-PuTTY-Release-0.52
2002-12-03 15:28:15 Using SSH protocol version 2
2002-12-03 15:28:16 Doing Diffie-Hellman group exchange
2002-12-03 15:28:16 Doing Diffie-Hellman key exchange
2002-12-03 15:28:17 Host key fingerprint is:
2002-12-03 15:28:17 ssh-rsa 1024 2f:49:82:46:cf:c7:02:cd:2a:dc:ff:16:9e:69:d1:0c
2002-12-03 15:28:17 Initialised AES-256 client->server encryption
2002-12-03 15:28:17 Initialised AES-256 server->client encryption
2002-12-03 15:28:24 Offered public key
2002-12-03 15:28:24 Server refused public key
2002-12-03 15:28:24 Keyboard-interactive authentication refused
2002-12-03 15:28:25 Sent password
2002-12-03 15:28:25 Access granted
2002-12-03 15:28:25 Opened channel for session
2002-12-03 15:28:25 Allocated pty
2002-12-03 15:28:25 Started a shell/command

Wat hier gebeurd... Ik krijg eerst mijn foutmelding... En vervolgens log ik in met mijn wachtwoord....

[LMD]

(Misschien gebruikt mijn ssh-server geen SSH2 protocol?, maar ik weet niet hoe ik dat kan controleren)

ssh -version

Mij lukt het ook niet wat jij wilt.
Dacht probeer het ook ff.
- Ik draai RedHat 7.2 met OpenSSH_3.1p1 & SSH protocols 1.5/2.0.
- Putty Release 0.53b

[Kees]

het werkt hier prima, maar daar heb je weinig aan

Zelf heb ik een rsa-key naar mijn lokale server toe, let er wel op dat de authorized key file 644 gechmod moet zijn, en gechowned op de user.group van die user.

Wat je verder aan debugging kan doen is sshd opstarten met -d (debugging), dan start hij op de voorgrond op en kan je zien wat er fout gaat.
Het kan ook zo zijn dat de server in de config de keys uit staan. Maar vaak geeft -d je al genoeg info over wat er mis is.

[Verwijderd]

Verwijderd schreef op 03 December 2002 @ 15:25:
Volgens mij moet je nog een passphase opgeven (wachtwoord) zonder deze is ssh niet veilig genoeg en gaat ie proberen om je gewoon in te loggen.

Ik wil eigenlijk zonder passphrase inloggen... (Om te testen). Dit moet ook kunnen!
Maar het is inderdaad niet zo heel erg veilig... Zodra dit werkt wil ik met een ssh-agent mijn passphrases gaan beheren....

Maar goed, ik heb het even geprobeerd... Maar helaas, levert dit geen resultaat op....

[Verwijderd]

Kees schreef op 03 December 2002 @ 15:33:
het werkt hier prima, maar daar heb je weinig aan

Zelf heb ik een rsa-key naar mijn lokale server toe, let er wel op dat de authorized key file 644 gechmod moet zijn, en gechowned op de user.group van die user.

Wat je verder aan debugging kan doen is sshd opstarten met -d (debugging), dan start hij op de voorgrond op en kan je zien wat er fout gaat.
Het kan ook zo zijn dat de server in de config de keys uit staan. Maar vaak geeft -d je al genoeg info over wat er mis is.

Kun jij hieraan zien wat er mis is dan?

Ik heb 'm gedebugged met: sshd -d -d -d

code:

debug1: userauth-request for user harm service ssh-connection method none
debug1: attempt 0 failures 0
debug2: input_userauth_request: setting up authctxt for harm
debug1: Starting up PAM with username "harm"
debug3: Trying to reverse map address 10.1.1.11.
Could not reverse map address 10.1.1.11.
debug1: PAM setting rhost to "10.1.1.11"
debug2: input_userauth_request: try method none
Failed none for harm from 10.1.1.11 port 3190 ssh2
debug1: userauth-request for user harm service ssh-connection method publickey
debug1: attempt 1 failures 1
debug2: input_userauth_request: try method publickey
debug1: test whether pkalg/pkblob are acceptable
debug1: temporarily_use_uid: 502/502 (e=0)
debug1: trying public key file /home/harm/.ssh/authorized_keys
debug1: restore_uid
debug1: temporarily_use_uid: 502/502 (e=0)
debug1: trying public key file /home/harm/.ssh/authorized_keys2
debug1: restore_uid
debug2: userauth_pubkey: authenticated 0 pkalg ssh-dss
Failed publickey for harm from 10.1.1.11 port 3190 ssh2
debug1: userauth-request for user harm service ssh-connection method keyboard-interactive
debug1: attempt 2 failures 2
debug2: input_userauth_request: try method keyboard-interactive
debug1: keyboard-interactive devs
debug1: auth2_challenge: user=harm devs=
debug1: kbdint_alloc: devices ''
debug2: auth2_challenge_start: devices
Failed keyboard-interactive for harm from 10.1.1.11 port 3190 ssh2

Kan aan mij liggen... Maar ik snap het niet....
Nogmaals van Linux naar Linux werkt het wel!

[Verwijderd]

De putty manual zegt :
Server refused our public key" or "Key refused"

Various forms of this error are printed in the PuTTY window, or written to the PuTTY Event Log (see section 3.1.3.1) when trying public-key authentication.

If you see one of these messages, it means that PuTTY has sent a public key to the server and offered to authenticate with it, and the server has refused to accept authentication. This usually means that the server is not configured to accept this key to authenticate this user.

This is almost certainly not a problem with PuTTY. If you see this type of message, the first thing you should do is check your server configuration carefully. Also, read the PuTTY Event Log; the server may have sent diagnostic messages explaining exactly what problem it had with your setup.

[Verwijderd]

Ik heb net mij config eens goed bekeken en als volgt ingesteld:

code:

#        $OpenBSD: sshd_config,v 1.48 2002/02/19 02:50:59 deraadt Exp $

# This is the sshd server system-wide configuration file.  See sshd(8)
# 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
#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 3600
#ServerKeyBits 768

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

# Authentication:

#LoginGraceTime 600
PermitRootLogin yes
#StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile      .ssh/authorized_keys

# rhosts authentication should not be used
#RhostsAuthentication no
# 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/ssh_known_hosts
#RhostsRSAAuthentication no
# similar for protocol version 2
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
#IgnoreUserKnownHosts no

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

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

# Kerberos options
# KerberosAuthentication automatically enabled if keyfile exists
#KerberosAuthentication yes
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes

# AFSTokenPassing automatically enabled if k_hasafs() is true
#AFSTokenPassing yes

# Kerberos TGT Passing only works with the AFS kaserver
#KerberosTgtPassing no

# Set this to 'yes' to enable PAM keyboard-interactive authentication 
# Warning: enabling this may bypass the setting of 'PasswordAuthentication'
#PAMAuthenticationViaKbdInt yes

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

#MaxStartups 10
# no default banner path
#Banner /some/path
#VerifyReverseMapping no

# override default of no subsystems
Subsystem        sftp        /usr/libexec/openssh/sftp-server

Ik zie het probleem niet.... Jullie wel?

[ Voor 1% gewijzigd door Verwijderd op 03-12-2002 15:47 . Reden: typo ]

[jvhaarst]

Ik heb net ook even lopen klooien, en bij mij deed ie het pas toen ik de files in .ssh/ op 644 had gezet.
Wat ik heb gedaan:
op server : ssh-keygen -t dsa
geen wachtwoord ingevuld.
op server : cat .ssh/id_dsa.pub >> .ssh/authorized_keys2
op server : chmod 644 .ssh/*
move de /.ssh/id_dsa naar de client.
Pas het formaat van de id_dsa aan zodat putty er wat mee kan met puttygen (import & export)

Gebruik die key als auth key in putty.

Klaar.

[Kees]

debug1: temporarily_use_uid: 502/502 (e=0)
debug1: trying public key file /home/harm/.ssh/authorized_keys
debug1: restore_uid
debug1: temporarily_use_uid: 502/502 (e=0)
debug1: trying public key file /home/harm/.ssh/authorized_keys2
debug1: restore_uid

Is / zijn die files leesbaar voor uid 502? en staat in die file ook de goede key?
probeer anders eens een RSA key.

[Creepy]

Verwijderd schreef op 03 December 2002 @ 15:01:
[...]


Ja, die heb ik in ~/.ssh/authorized_keys2 geplakt... Zie ook mijn eerste posting:

_{* Creepy moet leren lezen..}

[ Voor 3% gewijzigd door Creepy op 03-12-2002 15:53 ]

[Kees]

jvhaarst schreef op 03 december 2002 @ 15:49:
Ik heb net ook even lopen klooien, en bij mij deed ie het pas toen ik de files in .ssh/ op 644 had gezet.
Wat ik heb gedaan:
op server : ssh-keygen -t dsa
geen wachtwoord ingevuld.
op server : cat .ssh/id_dsa.pub >> .ssh/authorized_keys2
op server : chmod 644 .ssh/*
move de /.ssh/id_dsa naar de client.
Pas het formaat van de id_dsa aan zodat putty er wat mee kan met puttygen (import & export)

Gebruik die key als auth key in putty.

Klaar.

pas op hiermee..
niet zomaar je .ssh 644 chmodden, als je bijvoorbeeld (wat jij dus gedaan hebt) een identity maakt en die niet verplaatst dan is die dus ook worldreadable. Errug handig als iemand die te pakken krijgt, hij hij verdraaid weinig moeite te doen om als root in te loggen

[Verwijderd]

sterker nog, je .ssh dir zou (moet) 0700 zijn. De files in deze dir horen (moeten) op 0600 staan... (chmod -R go-rwx ${HOME}/.ssh)
_{maar dat is mijn paranoia insteek}

[ Voor 30% gewijzigd door Verwijderd op 03-12-2002 16:07 ]

[Verwijderd]

Lijkt me zowiso niet handig om een sshkey voor je root gebruiker te maken ZONDER wachtwoord...das vragen om problemen

[Verwijderd]

jvhaarst schreef op 03 december 2002 @ 15:49:
Ik heb net ook even lopen klooien, en bij mij deed ie het pas toen ik de files in .ssh/ op 644 had gezet.
Wat ik heb gedaan:
op server : ssh-keygen -t dsa
geen wachtwoord ingevuld.
op server : cat .ssh/id_dsa.pub >> .ssh/authorized_keys2
op server : chmod 644 .ssh/*
move de /.ssh/id_dsa naar de client.
Pas het formaat van de id_dsa aan zodat putty er wat mee kan met puttygen (import & export)

Gebruik die key als auth key in putty.

Klaar.

Nou, ik heb precies gedaan wat jij hier suggereert... Maar bij mij werkt het nog altijd niet! Volgens mij moet er haast wel iets niet goed zijn in mijn server config.... Kan jij misschien jouw /etc/ssh/sshd_config even posten....?

Ik krijg namelijk nog altijd:

code:

login as: harm
Server refused our key
harm@10.1.0.13's password:

[jvhaarst]

code:

[root@drunken-penguin root]# diff -Bb -c sshd_from_net /etc/ssh/sshd_config
*** sshd_from_net       Tue Dec  3 19:00:55 2002
--- /etc/ssh/sshd_config        Tue Jul  9 15:05:59 2002
***************
*** 11,17 ****
  # default value.

  Port 22
! Protocol 2
  #ListenAddress 0.0.0.0
  #ListenAddress ::

--- 11,18 ----
  # default value.

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

***************
*** 37,44 ****
  PermitRootLogin yes
  #StrictModes yes

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

  # rhosts authentication should not be used
--- 38,45 ----
  PermitRootLogin yes
  #StrictModes yes

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

  # rhosts authentication should not be used
***************
*** 87,93 ****

  #MaxStartups 10
  # no default banner path
! #Banner /some/path
  #VerifyReverseMapping no

  # override default of no subsystems
--- 88,94 ----

  #MaxStartups 10
  # no default banner path
! Banner /etc/issue.net
  #VerifyReverseMapping no

  # override default of no subsystems

Ik zie niet echt wat er mis is...

[Verwijderd]

Nou het is uiteindelijk gelukt... Het was inderdaad toch een geval van file permissions die niet helemaal goed stonden op de server. Dat is nu opgelost.
Echter heb ik nu nog 1 vraag.

In de post van jvhaarst beschrijft hij het volgende...

- Generatie van public en private key (op server)
- Dan cat hij de public key in de file ~/.ssh/authorized_keys
- Kopieert de private key naar de client.
- Importeert deze key met putty
- En gebruikt deze key om mee in te loggen.

Is dit niet de omgedraaide wereld? Ik dacht namelijk dat de public key naar de clients ging en de private key op de server bleef.

Hoe zit dat? Of moet het dus toch nog anders?

[jvhaarst]

Als je even naar die keys kijkt, dan zie je snel wat het verschil is.
De public key staat dus op de server, en de private bij je thuis. De public is een afgeleide va de private, niet andersom.

[Verwijderd]

Dat klopt. Maar het verwarrende is dat jij de keys op de server hebt gegenereerd... Terwijl hiervoor toch eigenlijk het puttygen programma bedoeld is? Of snap ik het nu helemaal niet meer.... Ik had me het volgende voorgesteld....

- Met puttygen een private en public key genereren
- De public key naar de server verhuizen en plakken in ~/.ssh/authorized_keys2
- De private key aangeven in putty als authentication
- inloggen....

[Verwijderd]

En dat werkt nu ook!

[jvhaarst]

puttygen is prima, maar die had ik even niet tot m'n beschikking, en dus gebruikte ik ssh-keygen.
In het kader van de handige tips het volgende:
Er is een plugin voor Total Commander (voormalig Windows Commander) om het te kunnen gebruiken als sftp client.