FS#18655 - [openssh] Permission denied (publickey).

Attached to Project: Arch Linux
Opened by Emmanuel (bkk_drs) - Friday, 12 March 2010, 17:04 GMT
Last edited by Aaron Griffin (phrakture) - Tuesday, 16 March 2010, 17:31 GMT
Task Type Bug Report
Category Packages: Testing
Status Closed
Assigned To Aaron Griffin (phrakture)
Architecture x86_64
Severity Critical
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
I can't ssh to my machine after upgrading to 5.4p1-2, I get a Permission denied (publickey) message

Package version: 5.4p1-2

Downgrading to 5.3p1-4 solves the issue
   ssh_permission_denied.txt (5.8 KiB)
   sshd_config (3.4 KiB)
This task depends upon

Closed by  Aaron Griffin (phrakture)
Tuesday, 16 March 2010, 17:31 GMT
Reason for closing:  Not a bug
Additional comments about closing:  Configuration issue
Comment by Lyubomir Grigorov (bgalakazam) - Friday, 12 March 2010, 20:07 GMT
Possibly not related, but I get error: Permission denied (publickey,keyboard-interactive) when trying to SSH to another machine on the network.
   ssh_config (1.5 KiB)
Comment by Linas (Linas) - Saturday, 13 March 2010, 20:27 GMT
No problem here connecting with public key to 5.4p1-2.
Are you also using openssh 5.4p1 as client?
Comment by Emmanuel (bkk_drs) - Sunday, 14 March 2010, 03:04 GMT
> Are you also using openssh 5.4p1 as client?
yes
$ pacman -Q openssh
openssh 5.4p1-2
Comment by Gavin Bisesi (Daenyth) - Sunday, 14 March 2010, 04:00 GMT
Does ssh -vvv tell you anything?

Edit: Ignore me, I shouldn't comment when tired.
Comment by Tomas Mudrunka (harvie) - Sunday, 14 March 2010, 17:42 GMT
Port 50775
ListenAddress 0.0.0.0
AllowUsers eb64 whowasphone
PermitRootLogin no
Match User whowasphone
ChrootDirectory /home/sftp
X11Forwarding no
AllowTcpForwarding no
ForceCommand internal-sftp

actualy you can login only using IPv4, only on port 50775 (unprivileged port may be problematic...) and only with eb64 user.
whowasphone is sftp-only (i guess you already know it, just for sure :-)

i have same openssh version and everything works great... have you tried default config? try to merge new options (u can use meld or some similat graphical diff tool) to your config...
Comment by Emmanuel (bkk_drs) - Sunday, 14 March 2010, 17:53 GMT
> try to merge new options (u can use meld or some similat graphical diff tool) to your config...
i vimdiff'd sshd_config and sshd_config.pacnew when the package has been installed, didn't see any new option or any syntax change or whatever modification.
i tried at least two different client machines on at least two different server machines, same problem.
Comment by Emmanuel (bkk_drs) - Tuesday, 16 March 2010, 03:56 GMT
would somebody with some free time be kind enough to test my sshd config to confirm he gets the same result ? also, just FTR, I tried the latest openssh testing package 5.4p1-3, same issue. thanks.
Comment by Aaron Griffin (phrakture) - Tuesday, 16 March 2010, 04:12 GMT
I'd recommend eliminating one setting at a time. Are you doing this as the whowasphone user? If so, perhaps permissions on the chroot dir is an issue
Comment by Emmanuel (bkk_drs) - Tuesday, 16 March 2010, 04:32 GMT
whowasphone is for some guests' sftp access only, I'm using the eb64 user mostly. [testing] version works fine with the "standard" password method but fails with a publickey. non-testing version still works perfectly. I'll try your suggestion about eleminating settings one at a time and report back.
Comment by Emmanuel (bkk_drs) - Tuesday, 16 March 2010, 08:07 GMT
ok, I risked my life and soul but I logged in #openssh and someone gave me the solution. do not try to find any logic behind this, what has to be done is to comment out those two lines:

#PubkeyAuthentication yes
#AuthorizedKeysFile .ssh/authorized_keys

this can be marked as solved I guess. however, a short message at install time may be a good idea as ssh is a very sensible package.
Comment by Emmanuel (bkk_drs) - Tuesday, 16 March 2010, 08:27 GMT
sorry for the spam guys (was better than editing) but the only thing that has to be commented out is:
#AuthorizedKeysFile .ssh/authorized_keys
Comment by Aaron Griffin (phrakture) - Tuesday, 16 March 2010, 15:48 GMT
That's a little odd, but apparently it does boil down to configuration issues.

Mind if I close the bug, then?
Comment by Emmanuel (bkk_drs) - Tuesday, 16 March 2010, 17:18 GMT
sure you can close it, no problem.

Loading...