Displaying 20 results from an estimated 20000 matches similar to: "[Bug 220] sshd fails to read other users authorized_keys over nfs as root"
2002 Jun 19
4
[Bug 220] sshd fails to read other users authorized_keys over nfs as root
http://bugzilla.mindrot.org/show_bug.cgi?id=220
------- Additional Comments From George.Baltz at noaa.gov 2002-06-20 01:23 -------
FWIW, I reported this to IBM Support, and they seem to agree realpath() is
broken. I have received a patched libc.a, which in light testing seems to
resolve the problem: public key login with perms 770 on ~/.ssh works.
------- You are receiving this mail
2002 Apr 17
6
[Bug 220] sshd fails to read other users authorized_keys over nfs as root
http://bugzilla.mindrot.org/show_bug.cgi?id=220
------- Additional Comments From markus at openbsd.org 2002-04-18 06:01 -------
i think i've seen this before and it was related to
the realpath() implementation....
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
2002 Apr 17
0
[Bug 220] New: sshd fails to read other users authorized_keys over nfs as root
http://bugzilla.mindrot.org/show_bug.cgi?id=220
Summary: sshd fails to read other users authorized_keys over nfs
as root
Product: Portable OpenSSH
Version: 3.0.2p1
Platform: All
URL: http://www.hut.fi/cc/
OS/Version: All
Status: NEW
Severity: major
Priority: P1
Component:
2003 May 14
3
[Bug 220] sshd fails to read other users authorized_keys over nfs as root
http://bugzilla.mindrot.org/show_bug.cgi?id=220
------- Additional Comments From djm at mindrot.org 2003-05-14 23:06 -------
Any followup on this, Ben?
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
2006 Oct 07
0
[Bug 1084] provide better error message if keys in authorized_keys contain CR/LF (was " sshd[6895]: fatal: buffer_get: trying to get more bytes 129 than in buffer 34")
http://bugzilla.mindrot.org/show_bug.cgi?id=1084
dtucker at zip.com.au changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |CLOSED
------- Comment #2 from dtucker at zip.com.au 2006-10-07 11:42 -------
Change all RESOLVED bug to CLOSED with the exception
2001 Dec 10
2
pubkey auth with NFS home on AIX
can someone confirm this:
http://bugzilla.mindrot.org/show_bug.cgi?id=29
Authentication refused: realpath /home/user/.ssh/authorized_keys failed: The file access permissions do not allow the specified action.
2012 Sep 14
5
[Bug 2042] New: Troubleshooting information should be logged when sshd doesn't have permission to read user's authorized_keys file
https://bugzilla.mindrot.org/show_bug.cgi?id=2042
Priority: P5
Bug ID: 2042
Assignee: unassigned-bugs at mindrot.org
Summary: Troubleshooting information should be logged when sshd
doesn't have permission to read user's authorized_keys
file
Severity: enhancement
Classification: Unclassified
2002 Jan 14
0
[Bug 66] New: $HOME/authorized_keys not read by sshd
http://bugzilla.mindrot.org/show_bug.cgi?id=66
Summary: $HOME/authorized_keys not read by sshd
Product: Portable OpenSSH
Version: -current
Platform: ix86
OS/Version: Linux
Status: RESOLVED
Severity: normal
Priority: P2
Component: sshd
AssignedTo: openssh-unix-dev at mindrot.org
ReportedBy:
2008 May 26
4
[Bug 1471] New: sshd can block if authorized_keys is a named pipe
https://bugzilla.mindrot.org/show_bug.cgi?id=1471
Summary: sshd can block if authorized_keys is a named pipe
Classification: Unclassified
Product: Portable OpenSSH
Version: 4.7p1
Platform: All
OS/Version: Linux
Status: NEW
Severity: minor
Priority: P2
Component: sshd
AssignedTo: bitbucket at
2003 Feb 06
4
[Bug 387] command="" in authorized_keys fails when sshd_config has "PermitRootLogon forced-commands-only"
http://bugzilla.mindrot.org/show_bug.cgi?id=387
markus at openbsd.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|FIXED |
------- Additional Comments From markus at openbsd.org 2003-02-07 08:16
2003 Jun 28
1
[Bug 219] authorized_keys documentation
http://bugzilla.mindrot.org/show_bug.cgi?id=219
------- Additional Comments From dtucker at zip.com.au 2003-06-28 14:52 -------
Created an attachment (id=340)
--> (http://bugzilla.mindrot.org/attachment.cgi?id=340&action=view)
Change authorized_keys description.
How about something like the attached? Or should this bug be closed as
WONTFIX?
------- You are receiving this mail
2003 Apr 13
2
chroot() as non-root user?
I suspect this has been asked before but I'll ask anyway.
Q1: Is it possible for a non-root process to perform a chroot?
My interest is this: I have a typical ISP hosting account (verio; on a
FreeBSD 4.4 server.) I'd like to install and run various CGI packages, yet
protect myself (and my email, and my .ssh keys) from bugs being exploited
in those CGI packages. Chroot at the start
2019 Jan 18
0
[klibc:master] rename, renameat: Use renameat2() system call
Commit-ID: ebdc262bd8a4d650c58de48f67e6b08aeb953a8f
Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=ebdc262bd8a4d650c58de48f67e6b08aeb953a8f
Author: Ben Hutchings <ben at decadent.org.uk>
AuthorDate: Mon, 16 Jul 2018 18:24:08 +0100
Committer: Ben Hutchings <ben at decadent.org.uk>
CommitDate: Fri, 18 Jan 2019 03:10:14 +0000
[klibc] rename, renameat: Use
2018 Mar 23
2
Call for testing: OpenSSH 7.7
On 24 March 2018 at 03:03, Corinna Vinschen <vinschen at redhat.com> wrote:
[...]
> session opened for local user corinna from [UNKNOWN]
> received client version 3
> debug2: Permitting whitelisted realpath request
> debug3: request 1: realpath
> realpath "."
> debug1: request 1: sent names count 1
> Refusing non-whitelisted statvfs request
>
2006 Oct 07
0
[Bug 1143] connections with "sshd: root@notty" is established but not closed
http://bugzilla.mindrot.org/show_bug.cgi?id=1143
dtucker at zip.com.au changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |CLOSED
------- Comment #3 from dtucker at zip.com.au 2006-10-07 11:44 -------
Change all RESOLVED bug to CLOSED with the exception
2007 Jun 28
5
[Bug 1326] New: Allow non-public-key credentials in authorized_keys file ( Kerberos, etc.)
http://bugzilla.mindrot.org/show_bug.cgi?id=1326
Summary: Allow non-public-key credentials in authorized_keys file
(Kerberos, etc.)
Product: Portable OpenSSH
Version: 4.4p1
Platform: All
OS/Version: Linux
Status: NEW
Severity: enhancement
Priority: P2
Component: Kerberos support
2002 Mar 21
0
StrictModes yes fails in some cases on AIX
today I've got a strange error on a AIX 4.3 box (OpenSSH 3.1p1)
secure_filename() fails with
"realpath /users/fmohr/.ssh/authorized_keys failed: Permission denied"
in a (realy special) case:
- /users/fmohr/ is mounted by the automounter
- the directory is exported via a dfs/nfs gateway
- StrictModes is set to yes
it works if the mounted directory is directly exported
via nfs or
2008 Dec 19
4
only root without password
Hi all,
I have a very strange problem with the public key authentication with 2
machines.
I generated the key, configured the authorized_keys etc.. etc.. This is
all ok, now:
The ssh works without the password for the "root" user, any other user
cannot use the key and ssh ask me for the password !!
I cannot understand why only the root is able to connect without the
password. So, the ssh
2002 Jun 09
0
[Bug 270] New: PrivSep breaks sshd on AIX for non-root users
http://bugzilla.mindrot.org/show_bug.cgi?id=270
Summary: PrivSep breaks sshd on AIX for non-root users
Product: Portable OpenSSH
Version: -current
Platform: PPC
OS/Version: AIX
Status: NEW
Severity: major
Priority: P2
Component: sshd
AssignedTo: openssh-unix-dev at mindrot.org
ReportedBy:
2002 Jun 09
3
[Bug 270] PrivSep breaks sshd on AIX for non-root users
http://bugzilla.mindrot.org/show_bug.cgi?id=270
------- Additional Comments From dtucker at zip.com.au 2002-06-09 19:59 -------
Created an attachment (id=111)
sshd output on AIX w/PrivSep
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.