similar to: [Bug 219] authorized_keys documentation

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

Hi, quick patch to ssh-copy-id to make it set the file modes more correctly. Thanks, Matthew --- contrib/ssh-copy-id.orig Thu Sep 27 21:47:44 2001 +++ contrib/ssh-copy-id Thu Sep 27 21:47:52 2001 @@ -33,7 +33,7 @@ exit 1 fi -{ eval "$GET_ID" ; } | ssh $1 "test -d .ssh || mkdir .ssh ; cat >> .ssh/authori zed_keys ; chmod g-w . .ssh .ssh/authorized_keys" +{ eval

Is there a risk associated with having authorized_keys files set to readable but "StrictMode no"? I am thinking particularly in the case of having public keys all centralized in a directory in /etc or something. Is it really a potential hack vector if someone can read a public key, or is the only real danger if they were writable? --- Don Hoover dxh at yahoo.com

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.

http://bugzilla.mindrot.org/show_bug.cgi?id=774 Summary: banner is displaying twice (/etc/issue) Product: Portable OpenSSH Version: 3.7.1p1 Platform: All OS/Version: Solaris Status: NEW Severity: security Priority: P2 Component: sshd AssignedTo: openssh-bugs at mindrot.org ReportedBy:

Hi, I would like to make it impossible for users to change the contents of the authorized_keys-file. I just found out about the sshd_config setting: AuthorizedKeysFile /etc/ssh/authorized_keys/%u But even in that case that file has to be owned by the user, unless I set ``StrictModes no'' which would allow other nastyness. I would like to request that that file could also be owned by

Greetings, I have compiled OpenSSH-3.6.1p2 on SCO 3.2v4.2 and the following problem occurs: I am unable to login as root using when strictmode is set to yes. output of debug: Failed none for root from 192.168.1.1 port 1199 ssh2 debug1: userauth-request for user root service ssh-connection method publickey debug1: attempt 1 failures 1 debug2: input_userauth_request: try method publickey debug1:

I was discussing with Don about a private topic..and while skimming the code I noticed that during a 'ssh mouring at site ls' the /etc/environment is *ONLY* read if the remote machine is an AIX box. This is undocumented and I'm wondering if someone using AIX could explain WHY it exists in the session.c:do_child()? No other OS has this. I don't see why AIX should require it.

http://bugzilla.mindrot.org/show_bug.cgi?id=219 ------- Additional Comments From markus at openbsd.org 2002-04-18 06:08 ------- hm, it's just required for StrictModes=yes. ------- 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=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.

This is just portable todo list. From the sounds of it Markus has his own to do list. But can everyone review and let me know if there is anything missing from this list. (Note.. I'm not looking for 'SSH should support XYZ feature.' unless it's directly related to portability.) Or if there is anything on this list that has been completed. (Namely Tru64 SIA support?) Thanks.

On Sat, Jul 9, 2016 at 10:30 AM, Ben Lindstrom <mouring at eviladmin.org> wrote: > You'd do this by either moving the authorized_keys to another a root owned > location using "AuthorizedKeysFile" (e.g. AuthorizedKeysFile > /etc/ssh/keys/authorized_keys.%u). Or you use "AuthorizedKeysCommand" and > put the keys into a "database" to reference

If we can get people to test their platforms against the last snapshot/cvs tree I'd be greatful. (http://www.openssh.com/portable.html) I know NeXT platform has problems. I'm going to spend tonight looking at it. Also, take a moment to see what manpage type ./configure decided for your system and if it's 'cat' please let us know. Thanks. - Ben

http://bugzilla.mindrot.org/show_bug.cgi?id=605 Summary: make install don't create piddir Product: Portable OpenSSH Version: -current Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: Build system AssignedTo: openssh-bugs at mindrot.org ReportedBy:

Howdy, I would like to suggest a change in the ssh documentation for the use of authorized_keys. The man page states: This file is not highly sensitive, but the recommended permissions are read/write for the user, and not accessible by others. I'm may be knit picking, but it could be read that, while not recommended, it is possible to allow access to the authorized_keys file to other

http://bugzilla.mindrot.org/show_bug.cgi?id=165 ------- Additional Comments From markus at openbsd.org 2002-03-17 04:31 ------- never seen this. what does sshd -ddd say? ------- 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=802 Summary: sshd of openssh-3.8p1 doesn't link on Tru64. Product: Portable OpenSSH Version: 3.8p1 Platform: Alpha OS/Version: OSF/1 Status: NEW Severity: normal Priority: P2 Component: Build system AssignedTo: openssh-bugs at mindrot.org

On Thu, Jul 7, 2016 at 10:00 AM, Bruce F Bading <badingb at us.ibm.com> wrote: > > Hi Gentlemen, > > Thank you both for your valued opinion. I do however agree that public key > authentication cannot be fully considered MFA as have 2 PCI QSAs I have > spoken with. This is because it is not enforceable server side. Many > things can affect client side security. >

Outside the known 'Hang-on-exit' bug and the Solaris 'PAM_TTY_KLUDGE' required. *WHAT* other issues *MUST* be address before 3.0 which is approaching fast? Those running NeXTStep I need conformation that it works under NeXT. My current Slab is packed in a storage unit due to a fire in my apartment complex (happened above me so I'm wrapping up dealing with that crap =). -

http://bugzilla.mindrot.org/show_bug.cgi?id=219 Summary: authorized_keys documentation Product: Portable OpenSSH Version: -current Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: Documentation AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: