Why studiyng whether GSSAPI works fine for me with heimdal, I tried to run sshd in foreground: # /var/tmp/portage/openssh-4.3_p2-r1/work/openssh-4.3p2/sshd -p 1234 -d debug1: sshd version OpenSSH_4.3p2 debug1: read PEM private key done: type RSA debug1: private host key: #0 type 1 RSA debug1: read PEM private key done: type DSA debug1: private host key: #1 type 2 DSA debug1: rexec_argv[0]='/var/tmp/portage/openssh-4.3_p2-r1/work/openssh-4.3p2/sshd' debug1: rexec_argv[1]='-p' debug1: rexec_argv[2]='1234' debug1: rexec_argv[3]='-d' debug1: Bind to port 1234 on 0.0.0.0. Server listening on 0.0.0.0 port 1234. socket: Address family not supported by protocol debug1: Server will not fork when running in debugging mode. debug1: rexec start in 4 out 4 newsock 4 pipe -1 sock 7 debug1: inetd sockets after dupping: 3, 3 Connection from 192.168.0.2 port 41954 debug1: Client protocol version 2.0; client software version OpenSSH_4.3 debug1: match: OpenSSH_4.3 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_4.3 debug1: list_hostkey_types: ssh-rsa,ssh-dss debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: client->server aes128-cbc hmac-md5 none debug1: kex: server->client aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: KEX done debug1: userauth-request for user mmokrejs service ssh-connection method none debug1: attempt 0 failures 0 debug1: PAM: initializing for "mmokrejs" debug1: PAM: setting PAM_RHOST to "vrapenec.doma" debug1: PAM: setting PAM_TTY to "ssh" Failed none for mmokrejs from 192.168.0.2 port 41954 ssh2 debug1: userauth-request for user mmokrejs service ssh-connection method publickey debug1: attempt 1 failures 1 debug1: test whether pkalg/pkblob are acceptable debug1: temporarily_use_uid: 1000/1000 (e=0/0) debug1: trying public key file /home/mmokrejs/.ssh/authorized_keys debug1: restore_uid: 0/0 debug1: temporarily_use_uid: 1000/1000 (e=0/0) debug1: trying public key file /home/mmokrejs/.ssh/authorized_keys2 debug1: restore_uid: 0/0 Failed publickey for mmokrejs from 192.168.0.2 port 41954 ssh2 debug1: userauth-request for user mmokrejs service ssh-connection method keyboard-interactive debug1: attempt 2 failures 2 debug1: keyboard-interactive devs debug1: auth2_challenge: user=mmokrejs devs= debug1: kbdint_alloc: devices 'pam' debug1: auth2_challenge_start: trying authentication method 'pam' Postponed keyboard-interactive for mmokrejs from 192.168.0.2 port 41954 ssh2 PAM: Authentication failure for mmokrejs from vrapenec.doma Failed keyboard-interactive/pam for mmokrejs from 192.168.0.2 port 41954 ssh2 debug1: Unable to open the btmp file /var/log/btmp: No such file or directory Is that a typo in sources? No, it is not. Are are aware of this file which is probably supposed to exist on Linux? - (dtucker) [auth.c canohost.c canohost.h configure.ac defines.h loginrec.c] Bug #974: Teach sshd to write failed login records to btmp for failed auth attempts (currently only for password, kbdint and C/R, only on Linux and HP-UX), based on code from login.c from util-linux. With ashok_kovai at hotmail.com, ok djm@
how do you know btmp is to blame ? did you do `touch /var/log/btmp` and things started magically working ? looks to me like you've got a pam issue: debug1: auth2_challenge_start: trying authentication method 'pam' Postponed keyboard-interactive for mmokrejs from 192.168.0.2 port 41954 ssh2 PAM: Authentication failure for mmokrejs from vrapenec.doma
No, I think PAM works fine: # /usr/sbin/sshd -p 1234 -d debug1: sshd version OpenSSH_4.3p2 debug1: read PEM private key done: type RSA debug1: private host key: #0 type 1 RSA debug1: read PEM private key done: type DSA debug1: private host key: #1 type 2 DSA debug1: rexec_argv[0]='/usr/sbin/sshd' debug1: rexec_argv[1]='-p' debug1: rexec_argv[2]='1234' debug1: rexec_argv[3]='-d' debug1: Bind to port 1234 on 0.0.0.0. Server listening on 0.0.0.0 port 1234. socket: Address family not supported by protocol debug1: Server will not fork when running in debugging mode. debug1: rexec start in 4 out 4 newsock 4 pipe -1 sock 7 debug1: inetd sockets after dupping: 3, 3 Connection from 192.168.0.2 port 56008 debug1: Client protocol version 2.0; client software version OpenSSH_4.3 debug1: match: OpenSSH_4.3 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_4.3 debug1: permanently_set_uid: 22/22 debug1: list_hostkey_types: ssh-rsa,ssh-dss debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: client->server aes128-cbc hmac-md5 none debug1: kex: server->client aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: KEX done debug1: userauth-request for user mmokrejs service ssh-connection method none debug1: attempt 0 failures 0 debug1: PAM: initializing for "mmokrejs" debug1: PAM: setting PAM_RHOST to "vrapenec.doma" debug1: PAM: setting PAM_TTY to "ssh" Failed none for mmokrejs from 192.168.0.2 port 56008 ssh2 debug1: userauth-request for user mmokrejs service ssh-connection method gssapi-with-mic debug1: attempt 1 failures 1 Postponed gssapi-with-mic for mmokrejs from 192.168.0.2 port 56008 ssh2 debug1: Received some client credentials Authorized to mmokrejs, krb5 principal mmokrejs/admin@DOMA (krb5_kuserok) debug1: do_pam_account: called Accepted gssapi-with-mic for mmokrejs from 192.168.0.2 port 56008 ssh2 debug1: monitor_child_preauth: mmokrejs has been authenticated by privileged process Accepted gssapi-with-mic for mmokrejs from 192.168.0.2 port 56008 ssh2 debug1: temporarily_use_uid: 1000/1000 (e=0/1000) debug1: restore_uid: 0/1000 debug1: PAM: reinitializing credentials debug1: permanently_set_uid: 1000/1000 debug1: Entering interactive session for SSH2. debug1: server_init_dispatch_20 debug1: server_input_channel_open: ctype session rchan 0 win 65536 max 16384 debug1: input_session_request debug1: channel 0: new [server-session] debug1: session_new: init debug1: session_new: session 0 debug1: session_open: channel 0 debug1: session_open: session 0: link with channel 0 debug1: server_input_channel_open: confirm session debug1: server_input_channel_req: channel 0 request pty-req reply 0 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req pty-req debug1: Allocating pty. debug1: session_new: init debug1: session_new: session 0 debug1: session_pty_req: session 0 alloc /dev/pts/7 debug1: server_input_channel_req: channel 0 request shell reply 0 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req shell debug1: PAM: setting PAM_TTY to "/dev/pts/7" debug1: Setting controlling tty using TIOCSCTTY. debug1: Received SIGCHLD. debug1: session_by_pid: pid 2956 debug1: session_exit_message: session 0 channel 0 pid 2956 debug1: session_exit_message: release channel 0 debug1: session_by_channel: session 0 channel 0 debug1: session_close_by_channel: channel 0 child 0 debug1: session_close: session 0 pid 0 debug1: channel 0: free: server-session, nchannels 1 Connection closed by 192.168.0.2 debug1: do_cleanup debug1: removing gssapi cred file"/tmp/krb5cc_gA2955" debug1: session_by_tty: session 0 tty /dev/pts/7 debug1: session_pty_cleanup: session 0 release /dev/pts/7 debug1: PAM: cleanup Closing connection to 192.168.0.2 debug1: PAM: cleanup # ls -la /var/log/btmp ls: /var/log/btmp: No such file or directory # OK, touching the does help, but I had to have the file non-group readable otherwise I was getting an additional error: Excess permission or bad ownership on file /var/log/btmp Finally, I have only root.root ownership and 'rw' by the user and sshd seems to write into the file happily. Seems it has utmp type binary structure. # utmpdump /var/log/btmp Utmp dump of /var/log/btmp [6] [03020] [ ] [mmokrejs] [ssh:notty ] [vrapenec.doma ] [192.168.0.2 ] [Mon May 22 22:54:45 2006 ] [6] [03020] [ ] [mmokrejs] [ssh:notty ] [vrapenec.doma ] [192.168.0.2 ] [Mon May 22 22:54:53 2006 ] [6] [03020] [ ] [mmokrejs] [ssh:notty ] [vrapenec.doma ] [192.168.0.2 ] [Mon May 22 22:54:57 2006 ] #
are there any problems with current openssh? if not please close this bug
Assuming obsolete bug. No response in 2+ years. Reopen if still broken.
The issue still does happen. Just enter some wrong string a a password: # /usr/sbin/sshd -p 1234 -d debug1: sshd version OpenSSH_5.1p1 debug1: read PEM private key done: type RSA debug1: private host key: #0 type 1 RSA debug1: read PEM private key done: type DSA debug1: private host key: #1 type 2 DSA debug1: rexec_argv[0]='/usr/sbin/sshd' debug1: rexec_argv[1]='-p' debug1: rexec_argv[2]='1234' debug1: rexec_argv[3]='-d' debug1: Bind to port 1234 on 0.0.0.0. Server listening on 0.0.0.0 port 1234. socket: Address family not supported by protocol debug1: Server will not fork when running in debugging mode. debug1: rexec start in 4 out 4 newsock 4 pipe -1 sock 7 debug1: inetd sockets after dupping: 3, 3 Connection from 127.0.0.1 port 57324 debug1: Client protocol version 2.0; client software version OpenSSH_5.1 debug1: match: OpenSSH_5.1 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.1 debug1: permanently_set_uid: 22/22 debug1: list_hostkey_types: ssh-rsa,ssh-dss debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: client->server aes128-cbc hmac-md5 none debug1: kex: server->client aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: KEX done debug1: userauth-request for user mmokrejs service ssh-connection method none debug1: attempt 0 failures 0 debug1: PAM: initializing for "mmokrejs" debug1: PAM: setting PAM_RHOST to "localhost" debug1: PAM: setting PAM_TTY to "ssh" Failed none for mmokrejs from 127.0.0.1 port 57324 ssh2 debug1: userauth-request for user mmokrejs service ssh-connection method password debug1: attempt 1 failures 0 debug1: temporarily_use_uid: 1000/1000 (e=0/0) debug1: restore_uid: 0/0 debug1: temporarily_use_uid: 1000/1000 (e=0/0) debug1: restore_uid: 0/0 debug1: Kerberos password authentication failed: Preauthentication failed debug1: krb5_cleanup_proc called debug1: PAM: password authentication failed for mmokrejs: Authentication failure Failed password for mmokrejs from 127.0.0.1 port 57324 ssh2 debug1: Unable to open the btmp file /var/log/btmp: No such file or directory # ssh -l mmokrejs 127.0.0.1 -v -p 1234 -2 OpenSSH_5.1p1, OpenSSL 0.9.8i 15 Sep 2008 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Connecting to 127.0.0.1 [127.0.0.1] port 1234. debug1: Connection established. debug1: permanently_set_uid: 0/0 debug1: identity file /root/.ssh/id_rsa type -1 debug1: identity file /root/.ssh/id_dsa type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1 debug1: match: OpenSSH_5.1 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.1 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-cbc hmac-md5 none 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 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: checking without port identifier debug1: Host '127.0.0.1' is known and matches the RSA host key. debug1: Found key in /root/.ssh/known_hosts:4 debug1: found matching key w/out port debug1: ssh_rsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,gssapi-with-mic,password debug1: Next authentication method: publickey debug1: Trying private key: /root/.ssh/id_rsa debug1: Trying private key: /root/.ssh/id_dsa debug1: Next authentication method: password mmokrejs@127.0.0.1's password: debug1: Authentications that can continue: publickey,gssapi-with-mic,password Permission denied, please try again. mmokrejs@127.0.0.1's password: In contrast if I enter valid kerberos or local password I get logged in and no complaints about missing btmp file are shown. The file gets updated. I think additional methods in openssh should print the same message that the file is missing.
Part of my sshd_config: PasswordAuthentication yes #PermitEmptyPasswords no ChallengeResponseAuthentication no KerberosAuthentication yes KerberosOrLocalPasswd yes KerberosTicketCleanup no KerberosGetAFSToken no GSSAPIAuthentication yes GSSAPICleanupCredentials no UsePAM yes
Hello, I think it is not mandatory to have the btmp file in the tree; take for example the output of the lastb command when the btmp file is absent. This output shows that the presence of the btmp file is discretionary to the administrator of the system. I suggest closing this bug as Invalid.
I propose Gentoo core team provides the btmp file pre-created for users.
(In reply to comment #8) > I propose Gentoo core team provides the btmp file pre-created for users. > Ditto... or, document what the correct ownership and perms are? I can't find that anywhere, yet.
(In reply to comment #9) > (In reply to comment #8) > > I propose Gentoo core team provides the btmp file pre-created for users. > > > > Ditto... or, document what the correct ownership and perms are? I can't find > that anywhere, yet. > Sorry, disregard. Pretty simple, really.
btmp is an old file I think, I don't see any reason for this bug anymore
the message about that missing file is still there with net-misc/openssh-6.2_p2-r4 created that file and had message from sshd about permissions.
the warning message about btmp not existing is normal and is safe to ignore. it does not cause or indicate any problems itself. if you want to use that functionality, then `touch` it so that openssh will start updating it automatically. if you don't, then ignore it.
