openssh bugs - Dec 2006 - [Bug 1266] incompatibility between s/key and keys Autentification

http://bugzilla.mindrot.org/show_bug.cgi?id=1266

           Summary: incompatibility between s/key and keys Autentification
           Product: Portable OpenSSH
           Version: 4.4p1
          Platform: ix86
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Miscellaneous
        AssignedTo: bitbucket at mindrot.org
        ReportedBy: GNUtoo at no-log.org


The problem is that i want to allow both keys and skey autentification

if i want the key autentification to be usefull i have to disable the
password Autentification fallback so that's what i've done:
PasswordAuthentication no
it worked fine and i was couldn't autentificate with passwords

after that i wanted to enable s/key in order to be able to login from
untrusted computers
so i've done:
ChallengeResponseAuthentication yes

after that i can logon with my password instead of the key!!!

in order to try it:
*migrate to keys instead of passwords
*add a user with a password and do not add keys to authorized_keys
try to logon with this username and password

solution:
or make the combinaison of PasswordAuthentication no and
ChallengeResponseAuthentication yes possible
or use one time keys instead of one time passworsds(would require more
work)




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=1266





------- Comment #1 from dtucker at zip.com.au  2006-12-04 07:22 -------
When you built OpenSSH, which options did you use?  In particular, did
you enable PAM?

I suspect that what you are seeing is keyboard-interactive
authentication via PAM, not password authentication.




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=1266





------- Comment #2 from GNUtoo at no-log.org  2006-12-04 07:56 -------
(In reply to comment #1)
> When you built OpenSSH, which options did you use?  In particular, did
> you enable PAM?
> 
> I suspect that what you are seeing is keyboard-interactive
> authentication via PAM, not password authentication.
> 
yes i have PAM
by the way i realy can login with the password of the acount...




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=1266





------- Comment #3 from dtucker at zip.com.au  2006-12-04 09:23 -------
(In reply to comment #2)
> yes i have PAM
> by the way i realy can login with the password of the acount...
PAM can do pretty much anything it wants under the covers, including
accept a password (or, indeed, do something like S/Key), but from a SSH
protocol perspective (which is what sshd_config is concerned about)
this is not "password" authentication.

If you set "UsePAM no" in sshd_config and restart sshd do you see the
same behaviour?




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=1266





------- Comment #4 from djm at mindrot.org  2006-12-04 09:53 -------
If want to use PAM, then you must configure the PAM ssh control file to
offer s/key authentication instead of password authentication.
Typically you would do this by replacing "pam_unix.so" in the
"password" section of the config file with a module for s/key.




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=1266





------- Comment #5 from GNUtoo at no-log.org  2006-12-05 03:34 -------
(In reply to comment #3)
> (In reply to comment #2)
> > yes i have PAM
> > by the way i realy can login with the password of the acount...
> 
> PAM can do pretty much anything it wants under the covers, including
> accept a password (or, indeed, do something like S/Key), but from a SSH
> protocol perspective (which is what sshd_config is concerned about)
> this is not "password" authentication.
> 
> If you set "UsePAM no" in sshd_config and restart sshd do you see
the
> same behaviour?
> 
no with pam disabled i have skey and key autentifications(skey doesn't
seems to work i don't know why...mabe i've missed something...i should
find a howto somewhere)




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=1266





------- Comment #6 from GNUtoo at no-log.org  2006-12-05 04:42 -------
now evrything works:
#       $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 23
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 yes
#StrictModes yes
#MaxAuthTries 6

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

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

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

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

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

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

# Set this to 'yes' to enable 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
# and ChallengeResponseAuthentication to 'no'.
UsePAM no

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

# no default banner path
#Banner /some/path

# here are the new patched ldap related tokens
# entries in your LDAP must have posixAccount & ldapPublicKey
objectclass
#UseLPK yes
#LpkLdapConf /etc/ldap.conf
#LpkServers  ldap://10.1.7.1 ldap://10.1.7.2
#LpkUserDN   ou=users,dc=phear,dc=org
#LpkGroupDN  ou=groups,dc=phear,dc=org
#LpkBindDN cn=Manager,dc=phear,dc=org
#LpkBindPw secret
#LpkServerGroup mail
#LpkForceTLS no
#LpkSearchTimelimit 3
#LpkBindTimelimit 3

# 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 no
#       AllowTcpForwarding no
#       ForceCommand cvs server




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.