Announce: OpenSSH 5.4 released

[Hu, Eric]

> -----Original Message-----
> From: openssh-unix-dev-bounces+eric.hu=harman.com at mindrot.org
> [mailto:openssh-unix-dev-bounces+eric.hu=harman.com at mindrot.org] On Behalf
> Of Corinna Vinschen
> Sent: Thursday, March 11, 2010 6:57 AM
> To: openssh-unix-dev at mindrot.org
> Subject: Re: Announce: OpenSSH 5.4 released
> 
> On Mar  7 19:05, Damien Miller wrote:
> >
> > OpenSSH 5.4 has just been released. It will be available from the
> > mirrors listed at http://www.openssh.com/ shortly.
> 
> There appears to be a new bug in OpenSSH affecting the sshd_config
> setting AuthorizedKeysFile.
> 
> The default entry in sshd_config is commented out:
> 
>   #AuthorizedKeysFile    .ssh/authorized_keys
> 
> Now, if you remove the # and restart sshd, it's suddenly impossible
> to login with public key authentication.  Running sshd in debugging
> mode shows entries like these:
> 
>   temporarily_use_uid: 500/513 (e=1105/513)
>   trying public key file //.ssh/authorized_keys
>   restore_uid: 1105/513
>   temporarily_use_uid: 500/513 (e=1105/513)
>   trying public key file //.ssh/authorized_keys
>   restore_uid: 1105/513
>   Failed publickey for some_user from 192.168.77.88 port 2864 ssh2
> 
> Note the paths to the authorized_keys file, which is not the
> user home directory, but the root directory instead.  Either
> commenting out the AuthorizedKeysFile directive in sshd_config,
> or replacing it with
> 
>   AuthorizedKeysFile    %h/.ssh/authorized_keys
> 
> fixes the issue.  It seems that the handling of the path as relative to
> the user's home directory has gone missing.  I don't see any comment in
> the release announcement, nor is there a change in the sshd_config man
> page which points to a planned change in AuthorizedKeysFile semantics.
> 
> 
> Corinna
> 
> --
> Corinna Vinschen
> Cygwin Project Co-Leader
> Red Hat
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

I saw this and was able to fix by prepending "%h" as well.  

In addition, a possibly related odd behavior with respect to ForceCommand that I'm seeing is that a command that was working is now showing the following on the server side in debug mode:

debug1: Forced command (config) './tunnel.sh'
debug2: fd 3 setting TCP_NODELAY
debug2: channel 0: rfd 8 isatty
debug2: fd 8 setting O_NONBLOCK
debug2: fd 6 setting O_NONBLOCK
debug1: Received SIGCHLD.
debug1: session_by_pid: pid 1328
debug1: session_exit_message: session 0 channel 0 pid 1328

and telling the client "./tunnel.sh: No such file or directory."  This was working fine with 5.1 (previously used version, hadn't upgraded in awhile).  The file "tunnel.sh" is in the user's home directory and the privileges have not changed from when it worked.

Another complication (also possibly related, but also possibly not) I'm seeing is different behavior when using public key authentication and password authentication.  The former results in a very limited bash shell.  PATH is set, but programs can't be executed, arrow and backspace keys don't work, things like that.  Password authentication works just as it had before.  On version 5.1, both methods yielded the same shell.

Eric