Bug#794568: OpenSSH server does not recognize principals option in authorized_keys file
On 08/04/2015 04:52 PM, Adam D. Barratt wrote: Control: tags -1 + moreinfo On 2015-08-04 15:10, Gordon Grubert wrote: [...] Disabling these options and using an user-based configuration in $HOME/.ssh/authorized_keys does not work. The authorized_keys file looks like cert-authority,principals=MYPRINCIPAL ssh-ed25519 C3NzaC1lZDI1NT. The ssh server says: Bad options in /root/.ssh/authorized_keys file, line 1: principals=MYPRINCIPAL ssh-ed25519 C3NzaC1lZDI1NT The syntax of the file authorzied_keys seems to be invalid, but this should be the syntax specified in man 8 sshd (section AUTHORIZED_KEYS FILE FORMAT). It's not - at least not precisely. sshd(8) says that the option is principals=principals The quotes are part of the syntax. I can replicate the error you're seeing by specifying principals=FOO, but principals=foo parses fine. You're right. Using quotes, everything is fine. IMHO, I had also tested this scenario. Obviously, I did not. I'm not sure, that the line principals=principals in sshd(8) says, that you have to use quotes. sshd(8) also says for the options: No spaces are permitted, except within double quotes. This implies, to use quotes for spaces only. Thx and best regards, Gordon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#794568: OpenSSH server does not recognize principals option in authorized_keys file
Package: openssh-server Version: 6.7p1-5 (Debian 8) Kernel : 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1 (2015-05-24) x86_64 GNU/Linux Using the options AuthorizedPrincipalsFile /etc/ssh/authorized_principals TrustedUserCAKeys /etc/ssh/UGCA_ssh.pub in /etc/ssh/sshd_config, a system-wide certificate based login with certificates (signed by the given CA) matching given principals in /etc/ssh/authorized_principals is possible. Disabling these options and using an user-based configuration in $HOME/.ssh/authorized_keys does not work. The authorized_keys file looks like cert-authority,principals=MYPRINCIPAL ssh-ed25519 C3NzaC1lZDI1NT. The ssh server says: Bad options in /root/.ssh/authorized_keys file, line 1: principals=MYPRINCIPAL ssh-ed25519 C3NzaC1lZDI1NT The syntax of the file authorzied_keys seems to be invalid, but this should be the syntax specified in man 8 sshd (section AUTHORIZED_KEYS FILE FORMAT). Best regards, Gordon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#726311: SAN Volumes cannot be mounted (using multipath)
Package: kpartx Version: 0.4.9+git0.4dfdaf2b-7~deb7u1 Severity: critical When updating kpartx from 0.4.9+git0.4dfdaf2b-6 to 0.4.9+git0.4dfdaf2b-7~deb7u1, SAN volumes cannot be mounted anymore. The SAN volumes are provided using multipath-tools. $ cat /etc/debian_version 7.2 $ uname -a Linux HOSTNAME 3.2.0-4-amd64 #1 SMP Debian 3.2.51-1 x86_64 GNU/Linux $ multipath -ll HOSTNAME-db (VOLUMEID) dm-0 IBM,2145 size=15G features='1 queue_if_no_path' hwhandler='0' wp=rw |-+- policy='round-robin 0' prio=25 status=active | |- 0:0:0:0 sda 8:0 active ready running | `- 1:0:1:0 sdj 8:144 active ready running `-+- policy='round-robin 0' prio=5 status=enabled |- 1:0:0:0 sdd 8:48 active ready running `- 0:0:1:0 sdg 8:96 active ready running After performing the package update, a system reboot has been performed, because the kernel had to be updated, too. Then, the following syslog entries have been found: Oct 14 11:02:14 HOSTNAME kernel: [ 19.092117] device-mapper: table: 254:7: multipath: error getting device Oct 14 11:02:14 HOSTNAME kernel: [ 19.092206] device-mapper: ioctl: error adding target to table $ mount /var/lib/mysql device mapper mount: /dev/sdj1 already mounted or /var/lib/mysql busy The volume has not been mounted already (checked in /proc/mounts). $ ls -l /dev/mapper total 0 crw--T 1 root root 10, 236 Oct 14 11:02 control lrwxrwxrwx 1 root root 7 Oct 14 11:02 HOSTNAME-db - ../dm-0 Here, the partition entry HOSTNAME-db-part1 is missing. Workaround: - downgrading kpartx to 0.4.9+git0.4dfdaf2b-6 - downgrading multipath-tools to 0.4.9+git0.4dfdaf2b-6 (both the packages are directly correlated) - set kpartx and multipath-tools to hold to prevent futher updates smime.p7s Description: S/MIME Cryptographic Signature
Bug#482348: Same problem with ldapdns
Hi, I've the same problem with ldapdns. It has been already present on Debian sarge and can still be found on Debian Lenny. Current packages: ii ldapdns 2.06-3.3 ii slapd 2.4.11-1 Kernel: Linux 2.6.26-2-amd64 Best regards, Gordon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#533595: Reference for man page markup (was: manpage-writer: Manual title in header should be uppercase)
On Fri, 31 Jul 2009, Ben Finney wrote: On 20-Jun-2009, Ben Finney wrote: My reference is the ‘man-pages(7)’ manual page from URL:http://www.kernel.org/doc/man-pages/online/pages/man7/man-pages.7.html: I have since been directed to the more specific ‘man(7)’ manual page URL:http://www.kernel.org/doc/man-pages/online/pages/man7/man.7.html. This has a lot of helpful information, including the section “Safe Subset”:: Although technically man is a troff macro package, in reality a large number of other tools process man page files that don’t implement all of troff’s abilities. Thus, it’s best to avoid some of troff’s more exotic abilities where possible to permit these other tools to work correctly. […] yes i read this, but the set of supported troff macros:: \, ., ad, bp, br, ce, de, ds, el, ie, if, fi, ft, hy, ig, in, na, ne, nf, nh, ps, so, sp, ti, tr. is long enough, the writer currently uses mainly the man macros .SH, ... and .sp , .in and the font mechanism test as you can and nag me. next for me would be the setup.py to release on pypi and get more testers this way. and after this a code cleanup. and probably release with docutils. cheers --
Bug#533593: manpage-writer: Remove extraneous newline characters in roff output
On Fri, 19 Jun 2009, Ben Finney wrote: Howdy Englebert, A newline character in roff markup is significant (unlike in, e.g., HTML), so it's important to only have newlines where they are necessary for the effect desired when the markup is rendered. The current manpage writer produces roff output with many extraneous newline characters. This results in large stretches of unwanted whitespace in the rendered man page. The attached patch against current VCS addresses this in the test input, but it may need to be modified in response to other tests. i am still at it, but viewing with man i seldom see a difference with/without your patch. except in one document is saw paragraphs flowwing together when your patch was applied. so i think i will have to do it stepwise, with a test for each change this will make manpage-writer more stable too. cheers -- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#533593: manpage-writer: Remove extraneous newline characters in roff output
On Fri, 19 Jun 2009, Ben Finney wrote: Howdy Englebert, A newline character in roff markup is significant (unlike in, e.g., HTML), so it's important to only have newlines where they are necessary for the effect desired when the markup is rendered. The current manpage writer produces roff output with many extraneous newline characters. This results in large stretches of unwanted whitespace in the rendered man page. The attached patch against current VCS addresses this in the test input, but it may need to be modified in response to other tests. right , i have to see, in some cases paragraph separation is missing. cheers -- \ “Are you pondering what I'm pondering?” “I think so, Brain, but | `\why would anyone want a depressed tongue?” —_Pinky and The | _o__) Brain_ | Ben Finney b...@benfinney.id.au --
Bug#297004: acknowledged by developer (kernel-image: setup initrd symlinks is confusing)
On Tue, 1 Mar 2005, Debian Bug Tracking System wrote: This is an automatic notification regarding your Bug report #297004: kernel-image: setup initrd symlinks is confusing, which was filed against the kernel-package package. It has been closed by one of the developers, namely Manoj Srivastava [EMAIL PROTECTED] (va, manoj). Their explanation is attached below. If this explanation is unsatisfactory and you have not received a better one in a separate message then please contact the developer, by replying to this email. Debian bug tracking system administrator (administrator, Debian Bugs database) The messages in question are: == Setting up kernel-image-2.6.8-2-686 (2.6.8-13) ... /initrd.img does not exist. Installing from scratch, eh? Or maybe you don't want a symbolic link here. Hmm? Lets See. I notice that you do not have initrd.img symbolic link. I can create one for you, and it shall be updated by newer kernel image packages. This is useful if you use a boot loader like lilo. Do you want me to create a link from /boot/initrd.img-2.6.8-2-686 to initrd.img?[Yn] Do you want me to create a link from /boot/initrd.img-2.6.8-2-686 to initrd.img?[Yn] == Here, as should be clear, we are talking about initrd.img. == I note that you have an old /boot/initrd symbolic link in place. The location of the symbolic link is now the same location as the kernel image symbolic links, names, in $image_dest. I have two options here. I can: (A) delete the old symbolic link (default). You shall need to update the boot loader (b) Igore it and do nothing Please select one of a, or b: == I fail to see how this could be any clearer. and here are we talking of what initrd or initrd.img ? i guess it is the old initrd link ? as debian uses initrd.img why does it bother with the old initrd symlink ? cheers -- BINGO: Support your right to bare arms! Wear short sleeves! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
