Re: Having problem with Debian's Installation Guide Preparing Files for USB Memory Stick Booting

2016-10-28 Thread Stephan Beck
Hi,

billwill onggo:
> I was trying to create a bootable USB flash disk following this guide :
> 4.3.3.2. Preparing Files For USB Memory Stick Booting > the flexible way >
> adding installer image
> https://www.debian.org/releases/stable/amd64/ch04s03.html.en#usb-copy-flexible
> 
> 
> Booting the USB installer gives me a 'kernel panic - vfs unable to mount
> root fs' booting the USB installer
> 
> This is strange, because several months ago i did successfully create a
> debian installer, using the same cd-image, following this same guide, and
> installed this Debian (i'm currently using to write this mail) into this
> machine.
> 
> After struggling almost an hour, i got it working. I found that the content
> of the syslinux.cfg is the culprit since I cant boot without the
> syslinux.cfg file and manually provide the boot parameter at boottime
> 
> boot: vmlinuz initrd=initrd.gz

I can't follow you here. If you really follow the installation guide
ch04s03.html.en#usb-copy-flexible, you have to create a syslinux.cfg
yourself, there is no existing syslinux.cfg (content), as you seem to be
telling us. Be aware that within 4.3. there are several ways:
syslinux.cfg does exist as a file using 4.3.2 as part of the
hd-media/boot.img.gz.
Did you select that? If not, there is no existing syslinux.cfg file.

[...]

Doing it the flexible way, the content of the syslinux.cfg to be created
should be (it's from the stick I used for a real installation, so
priority=medium is optional) :

default vmlinuz initrd=initrd.gz priority=medium

If you want to have the installer boot with that, but additionally want
to add some parameters at boot time, add a

prompt 1

line to the syslinux.cfg.
Please check that you haven't done steps that actually do not belong to
"the flexible way".

> 
> This is content of the syslinux.cfg the from installation guide :

Yes, you're talking about a not so flexible way.
> 
>> default vmlinuz
>> append initrd=initrd.gz
>>
>> Shouldn't it be something like this?
> 
>> default debi
>>
>> label debi
>> kernel vmlinuz
>> append initrd=initrd.gz
>>
Can't tell you anything about whether your observation here is right or
wrong.

Cheers

Stephan



Fwd: Re: archivemail default setup

2016-10-22 Thread Stephan Beck
To the list as well...


 Forwarded Message 
Subject: Re: archivemail default setup
Date: Sat, 22 Oct 2016 13:00:00 +
From: Stephan Beck <sb...@secure.mailbox.org>
Reply-To: sb...@secure.mailbox.org
To: Mark Fletcher <mark2...@gmail.com>

Hi Mark,

Mark Fletcher:
> Hello again
> 
> A little while back I installed archivemail on Jessie, to delete mail 
> from my local mailbox when it is more than a month old.
> 
> The command I am running is:
> 
> archivemail --output-dir=/home/mark/Mail/ -d 31 --delete /var/mail/mark
> 
> My mailbox is in /var/mail/mark. I didn't choose to put it there, that 
> is where it went when the system was installed. I am not sure if that is 
> thanks to the default settings of exim4, mutt, or something else.
> 
> Now /var/mail is owned by root:mail and had access 775. /var/mail/mark 
> is owned by mark:mail and has permissions 660.
> 
> Whenever I ran archivemail as mark, it was complaining that it did not 
> have write access to /var/mail (it wanted to write a lock file) and then 
> proceeded to say it was deleting 0 messages.
> 
> The oldest messages in my mail folder are dated September 18th and as 
> such should have been deleted by now. They are not being because, I 
> suppose, of the failure to write the lock file. 
> 
> When I run archivemail as root it complains that I am not the owner of 
> the mailbox and refuses to do anything.

You may use the setgid command option (on /var/mail) in order to achieve
that any new file created there (and the directory /var/mail/mark is
just a file like that) has its group ownership set to the group owner of
the directory (which should be "mail") rather the group ownership of the
file's creator.
ls -l /var/mail
(as root)
chmod g+s /var/mail
Then you have to add user mark to the mail group:
(as root)
adduser mark mail
(effective upon next login)
If you then start
/usr/bin/archivemail as user mark (who as a member of the group "mail"
has r/w access to all files in /var/mail/mark)

it should have access to the files.

> 
> It seems that if the mailbox is in the default out-of-the-box place then 
> archivemail can't use it properly. It seems like archivemail is 
> expecting my mailbox (its input) to be in a folder to which I will have 
> write access. It seems to me that a package should ship with default 
> assumptions that can be met by the other packages in the distro.
> 
> Now, I have got away from the error by making /var/mail world-writable, 
> but I don't like that solution. Is there a better one? Will I have to 
> move my mailbox to a different location, eg my home directory, and if so 
> how do I safely do that in a way that won't break anything (I am using 
> exim4 and mutt and I don't know what other infrastructure might be 
> involved that would care, for example I keep hearing about something 
> called procmail but don't know if that is actually involved in handling 
> mail on my system)

To see where the binary is located:
echo $(which procmail)
Yes, procmail is probably involved as Mail Delivery Agent (MDA), locally
delivering the mail from the MTA (exim4) to your local mail account mark.
You might check this setting in the appropriate exim4 conf file.


My 2 cents

Stephan



Inclusion of devices in the Info.plist of ccid [was]Re: Pardonnez-moi [was Re: libccid's Info.plist update in Stretch removing Nitrokey Smartcard products?]

2016-10-20 Thread Stephan Beck
Stephan Beck:
> Hi Børge,
> 
> Børge Holen:
>> On 18 Oct 2016 16:19, "Stephan Beck" <sb...@secure.mailbox.org> wrote:
> 
>>> The only question then is why are the Nitrokey USB crypto sticks not
>>> included in libbcid's Info.pList file? They showed up on the scene years
>>> ago.
>>>
>>> But maybe that's a question that should be directed to the package
>>> maintainer or "upstream" directly.
>>>
> 
>>
>> I had the creator of the libccid add a smartcard reader a couple of years
>> ago. Took a week or so before it landed in debians reposatories. Painfree
>> process. I to added it manually before that. A cherry card reader if im not
>> mistaken...
> 
> Ah, I didn't know that it's that easy. Thanks for your info. I think
> I'll give it a try.
> 
> Cheers
> 
> Stephan

Well, Børge, it seems that I wasn't as lucky as you. I asked upstream to
have Nitrokey included but he says that payment is needed for an
inclusion in the list of supported readers, as this inclusion requires
to pass a test suite that he has set up, and he does not do that for
free (a very respectable decision).
I deduce from that, that (even in your case) it have to be the
makers/suppliers who have to be sufficiently interested in having their
devices included in the list, i.e. interested to an extent that they pay
for the required tests to be performed.

Cheers

Stephan



Re: Pardonnez-moi [was Re: libccid's Info.plist update in Stretch removing Nitrokey Smartcard products?]

2016-10-19 Thread Stephan Beck
Hi Børge,

Børge Holen:
> On 18 Oct 2016 16:19, "Stephan Beck" <sb...@secure.mailbox.org> wrote:

>> The only question then is why are the Nitrokey USB crypto sticks not
>> included in libbcid's Info.pList file? They showed up on the scene years
>> ago.
>>
>> But maybe that's a question that should be directed to the package
>> maintainer or "upstream" directly.
>>

> 
> I had the creator of the libccid add a smartcard reader a couple of years
> ago. Took a week or so before it landed in debians reposatories. Painfree
> process. I to added it manually before that. A cherry card reader if im not
> mistaken...

Ah, I didn't know that it's that easy. Thanks for your info. I think
I'll give it a try.

Cheers

Stephan



Pardonnez-moi [was Re: libccid's Info.plist update in Stretch removing Nitrokey Smartcard products?]

2016-10-18 Thread Stephan Beck
Hi,

now I understand what might have happened.
I guess that the Nitrokey USB token wasn't even included in the
Info.plist file, and I probably had added those entries manually long
time ago, about 9 months ago. This is the only explanation I can find
for the result of the diff.

So, the maintainer might excuse the fact that I was no longer aware of
this.
The only question then is why are the Nitrokey USB crypto sticks not
included in libbcid's Info.pList file? They showed up on the scene years
ago.

But maybe that's a question that should be directed to the package
maintainer or "upstream" directly.

Cheers

Stephan

Stephan Beck:
> Hi all,
> 
> when I updated my Debian testing installation on Friday using sudo
[...]



libccid's Info.plist update in Stretch removing Nitrokey Smartcard products?

2016-10-18 Thread Stephan Beck
Hi all,

when I updated my Debian testing installation on Friday using sudo
apt-get update and sudo apt-get upgrade, a note made by what appears to
be the libccid package maintainer was displayed, on the need to update
its /usr/lib/pcsc/drivers/ifd-ccid.bundle/Contents/Info.plist file.

When I looked at the diff, there were several new smartcard items added,
but there were only 4 items removed from the Info.plist file (being
marked as "-"), all belonging to the Nitrokey smartcard products. There
wasn't any other explanatory note. I did not update and continued with
the update of the rest of the packages.

So, why were those items/entries identifying Nitrokey smartcards
(Nitrokey Pro, Nitrokey storage, etc.) removed from the updated file?


Can anybody else confirm that their file got updated in that way?

Thanks in advance

Stephan



Re: Automated install entry menu of Debian installer does not ask pressed file path / url

2016-10-15 Thread Stephan Beck
Hi,

John Gathm:
> Hi
> 
> just not running anything.
> Just discovering that a behavior of previous Debian installer is either
> broken or has been removed, and asking if others see the same behavior.
> 
> Will report a bug.
> 
> J.G

well, I gave you the info so that you were able to see that the
documentation is *aware of the fact* that from wheezy installer to
jessie installer things have changed, and therefore it's probable that
you run into issues here. You are always free to file a bug, but you can
also check if there has been a documented change in (1), that might
affect your installation process.

Quote:
3.1.2. Automated installation

Some changes mentioned in the previous section also imply changes
in the support in the installer for automated installation using
preconfiguration files. This means that if you have existing
preconfiguration files that worked with the wheezy installer, you
cannot expect these to work with the new installer without
modification.

The Installation Guide (https://www.debian.org/releases/jessie/
installmanual) has an updated separate appendix with extensive
documentation on using preconfiguration.

It was Section 3.1.2 of Jessie's release notes, not 3.2, as I
erroneously stated in my previous mail.

Cheers,

Stephan

(1) https://www.debian.org/devel/debian-installer/News/



Re: Automated install entry menu of Debian installer does not ask pressed file path / url

2016-10-14 Thread Stephan Beck
Hi John,

John Gathm:
> hello,
> 
> As strange as it may sound, the "automated install" entry of the Debian
> installer CD seems to be broken on Jessie.
> When I select "automated install" in the boot menu I am not prompted (after
> the usual network setup ) with the dialog to enter pressed file path/url.
> This happens in VirtualBox or on real hardware, either in BIOS or UEFI mode.
> This works fine with wheezy installer.
> Anyone met the same issue ?

Instead of guessing what might be the issue here:
Have you read section 3.2 of the jessie release notes (1)?
Have you read the Appendix B (especially B.1.1.)of the install doc
available for Jessie (2)?
Maybe you can find the solution to your specific problem there.

Guesses:
you are running automated install with debconf priority critical and, as
a consequence, this question is being (deliberately) omitted.
you are already using preseed via initrd which is loaded directly at the
beginning of the install process and thus are waiting in vain for the
prompt to appear.
But I don't like guessing without more info so I refer you to the docs.

Cheers

Stephan


(1)https://www.debian.org/releases/jessie/releasenotes
(2)https://www.debian.org/releases/jessie/installmanual



Re: Best Ultrabook for Debian

2016-10-06 Thread Stephan Beck
Hi Hörmetjan,

Hörmetjan Yiltiz:
> Hi all,
> 
> I am aware of the h-node project, as well as the linux-desktop, and the
> Debian's hardware wiki page. However, they are not quite specific about
> Ultrabooks at all.
> 
> Ultrabooks are arguably the trend in PCs (if not cellphones), and we all
> aim for lighter and better hardware. I would like to be able to: bull the
> ultrabook directly from within US (preferably through Internet), install
> (or pre-installed) Debian testing and all the necessary *free* hardware
> drivers and firmwares, and use every hardware that comes with it (wireless
> card, graphics, touch-screen, touchpad etc.) to the extent that the
> manufacturer supports (for other platforms).
> 
> Is there such a ultrabook model yet? If so, what are our models that allow
> us to use (as much) free software to get the best user experience?

something like that?
Eveń if they don not run Debian (or maybe it's possible, but I don't
know), but have a strong focus on libre hardware/software, maybe it's
worth checking out
https://shop.libiquity.com/product/taurinus-x200 (US)
https://minifree.org/product/libreboot-x200/ (outside US)

Cheers,

Stephan



[SOLVED ]Re: Issues with SSH pubkey authentication at remote server

2016-09-28 Thread Stephan Beck
Hi,

to...@tuxteam.de:
> On Wed, Sep 28, 2016 at 08:36:00AM +0000, Stephan Beck wrote:
>> Hi Lars,
> 
>> Lars Noodén:
>>> On 09/27/2016 06:07 PM, Stephan Beck wrote:
>>>> Lars Noodén:
>>>>> On 09/27/2016 02:02 PM, Stephan Beck wrote:
>>>>> Can you tell more about how your login session is started?
>>>>
>>>> I connect to the "local ssh account" by ssh from my other user account.
>>>
>> [...]
[...]
> Yes. It depends. If you're typically using X as your environment
> (perhaps via some desktop thing: in your case it seems to be LXDE),
> then the first go to is your desktop thing's session management.
> 
> This way all consoles you start will inherit the "coordinates" of
> the agent (in the form of the shell variables SSH_AGEN_PID,
> SSH_AUTH_SOCK and perhaps others I forget). With no desktop environ
> (plain X), X session management (see /etc/X11/XSession.d for
> Debian; there is a 90x11-common_ssh-agent for that). Otherwise
> you have to cook up something in your ~/.profile which looks
> whether there's an agent around and set it up when no. In a nutshell
> 
> 
>   - using a DE: your DE's session management
>   - X without DE: X session management
>   - naked console: .login, .profile (or .bash_profile, .bash_login)

Thanks, Tomás. I'll think about what might be the best solution for me.
Configuring LXDE-Startup applications is maybe the best (and easiest)
solution, whereas adapting ~/.profile I'd be forced to train my console
skills, although that would mean that it only affects this specific user
account.

Cheers,

Stephan


I put SOLVED in the subject line, because the "real" issue, the pubkey
authentication at the remote server is working fine now.



Re: Issues with SSH pubkey authentication at remote server

2016-09-28 Thread Stephan Beck
Hi Lars,

Lars Noodén:
> On 09/27/2016 06:07 PM, Stephan Beck wrote:
>> Lars Noodén:
>>> On 09/27/2016 02:02 PM, Stephan Beck wrote:
>>> Can you tell more about how your login session is started?
>>
>> I connect to the "local ssh account" by ssh from my other user account.
> 
[...]
> You need a way for your "local ssh account" to start and use an agent.
> I'm not sure of the optimal way for you.  Perhaps something in .bashrc?
> Others here know more about the shells than I.

Or in .profile. But I am not really sure about the exact syntax to use
(this if/then "thing"). I still have to get familiar with that.

I just checked in LX Session Configuration that the ssh-agent is
configured as -->Core applications but disabled in --> Autostart. So
there is another program/process/script that has to be launching the
ssh-agent, because I find it twice in the process list when I login to
my "normal" user account. I'm shivering :-)

I'll keep you informed.

Thanks again.

Stephan



Re: Issues with SSH pubkey authentication at remote server

2016-09-27 Thread Stephan Beck
Hi Lars,

Lars Noodén:
> On 09/27/2016 02:02 PM, Stephan Beck wrote:
>> Hi Lars,
>>
>> Lars Noodén:
>>> On 09/26/2016 05:46 PM, Stephan Beck wrote:
[sorry for trimming]

>> I've tried again and detected the following:
>> No agent is started when I login to the "local ssh user account".
> 
> It is the one that should be running under your local account that is of
> relevance, or at least should be.  How are you logging in to your "local
> ssh user account" there?
[...]

>Can you tell more about how your login session is started?

I connect to the "local ssh account" by ssh from my other user account.
Now I've tried it several times always repeating this
eval $(ssh-agent)
ssh-add /path/to/key
ssh-add -L (for checking)
procedure and I do not have to enter the passphrase for this session.
>From my point of view I do not need to have the same env in the "local
ssh account" as I have in the other account.

Thanks
Stephan





Re: Issues with SSH pubkey authentication at remote server

2016-09-27 Thread Stephan Beck
Hi Lars,

Lars Noodén:
> On 09/26/2016 05:46 PM, Stephan Beck wrote:
>> ... it might
>> not be necessary to fire it up with eval $(ssh-agent).
>> Thanks for the command, makes it more easy.
> 
> No problem.  If you want to see which keys are available to ssh, you can
> use ssh-add for that:
> 
>   ssh-add -L
> 
> It has to be run in the same shell as you would then run ssh.
> 
> That will list the public key matching the private key which has
> actually been loaded into the available agent.  But that availability
> might be the issue here, as with the earlier message, I am still
> wondering if ssh is finding the "right" agent.

I've tried again and detected the following:
No agent is started when I login to the "local ssh user account".
I have to do
eval $(ssh-agent) --> for every single session
ssh-add /path/to/key
ssh-add -L
(outputs the key)
Then I connect to the remote server and it works without having to type
a passphrase. Gee!

The fact that there are two ssh-agents under my other user account,
one with the -s option, the other exits with LX session, is still under
investigation :-)

Thanks
Stephan



OpenSSH security update? was Re: Issues with SSH pubkey authentication at remote server

2016-09-27 Thread Stephan Beck
Hi,

[UPDATE]
Stephan Beck:
> Hi Mark,
> 
> Mark Fletcher:
>> On Mon, Sep 26, 2016 at 02:52:00PM +0000, Stephan Beck wrote:
>>> Hi Lisi,
>>
>>> If you look at the second line of the terminal output I reproduced, you
>>> find that the openssl component in use within the package openssh Debian
>>> Jessie is one step behind. "Standalone" OpenSSL package is now at
>>> version 1.0.1t-1+deb8u5 since September 23.
>>>
>>>> me@mymachine:~/.ssh$ ssh -vv me@theremoteserver
>>>> OpenSSH_6.7p1 Debian-5+deb8u3, OpenSSL 1.0.1t  3 May 2016
>>>
>> Yeah there was a Debian security advisory last week with a security 
>> patch for OpenSSL. I thought the fix was already in place, certainly I 
>> got an update for OpenSSH when I updated on Sunday.
> 
> I didn't receive any update of the OpenSSH package in the past days.
> Such update would usually be communicated issuing a DSA urging people to
> upgrade, wouldn't it? And I'm subscribed to the DSA.
> Just checked and as latest I upgraded the libarchive package.

not even activating deb-src (security) and deb-src (ftp.xx.debian.org)
Sources
apt-get update
apt-get upgrade

results in any OpenSSH package being updated.

In packages.debian.org I see a sources patch that can be manually
downloaded and applied. But nothing you "get", as you say.

So, am I right? It is not included in the .deb sources that are
accessible (provided there is the entry in apt-sources.list) using the
above apt commands.

Cheers

Stephan



Re: Issues with SSH pubkey authentication at remote server

2016-09-27 Thread Stephan Beck
Hi Dan,

Dan Purgert:
> Stephan Beck wrote:
>> Dan Purgert:
>>> Mark Fletcher wrote:
>>>> If I'm reading the above right, it looks like the server is offering an
>>>> rsa key to authenticate itself, but won't accept rsa to authenticate the
>>>> client. Which is a bit cheeky.
>>>
>>>> You may need a key created with a stronger method, such as ecdsa or
>>>> ed25519.
>>>
>>> Could even be as simple as he sent a /different/ key across (e.g. he
>>> sent "home-key.pub", which corresponds to "home-key_rsa" rather than
>>> "id_rsa").
>>>
>> No. I wrote that I /checked/ the public key copied to the server after
>> having copied it to the server's ~/.ssh directory. I edited it with a
>> text editor and compared it with the one I have in local ~/.ssh
> 
> 
> I think you misunderstood what I was saying.  I was supposing that you
> copied a valid (yet "incorrect") key to the remote server, or tried to
> authenticate with the wrong private key.

It was the correct and valid public key. It seems that the agent
actually is authenticating with the wrong private key. But, fair to say,
that's something you didn't mention in your first message.
> 
> For example, I have in my user's .ssh/ directory:
> 
> id_rsa -> symlink to home_lan_rsa
> VPS_id_rsa -> private key for uploading to a VPS
> home_lan_rsa -> private key for use on my LAN.
> 
> Assuming that I copied the right public key to the VPS, if I run the
> command "ssh me@vps", it'll fail, because ssh by default tries to
> authenticate with "id_rsa". _FIX:_ change the ssh command to "ssh -i
> .ssh/VPS_id_rsa me@vps"

Well, I only have one single pubkey on this local user "ssh" account I'm
talking about.

Cheers
Stephan



Re: Issues with SSH pubkey authentication at remote server

2016-09-27 Thread Stephan Beck
Hi Mark,

Mark Fletcher:
> On Mon, Sep 26, 2016 at 02:52:00PM +0000, Stephan Beck wrote:
>> Hi Lisi,
> 
>> If you look at the second line of the terminal output I reproduced, you
>> find that the openssl component in use within the package openssh Debian
>> Jessie is one step behind. "Standalone" OpenSSL package is now at
>> version 1.0.1t-1+deb8u5 since September 23.
>>
>>> me@mymachine:~/.ssh$ ssh -vv me@theremoteserver
>>> OpenSSH_6.7p1 Debian-5+deb8u3, OpenSSL 1.0.1t  3 May 2016
>>
> Yeah there was a Debian security advisory last week with a security 
> patch for OpenSSL. I thought the fix was already in place, certainly I 
> got an update for OpenSSH when I updated on Sunday.

I didn't receive any update of the OpenSSH package in the past days.
Such update would usually be communicated issuing a DSA urging people to
upgrade, wouldn't it? And I'm subscribed to the DSA.
Just checked and as latest I upgraded the libarchive package.

Cheers
Stephan



Re: Issues with SSH pubkey authentication at remote server

2016-09-26 Thread Stephan Beck
Hi Lars,

Lars Noodén:
[...]
>   ssh-add -L
> 
> It has to be run in the same shell as you would then run ssh.
> 
> That will list the public key matching the private key which has
> actually been loaded into the available agent.  But that availability
> might be the issue here, as with the earlier message, I am still
> wondering if ssh is finding the "right" agent.

OK. I've successfully established ssh connection via pubkey auth, which
did not work because I thought I had to ssh-copy-id it in ~/.ssh whereas
it has to be placed in /.ssh. BUT
--
debug1: Offering [key_cipher_type] public key: ~/.ssh/[key_cipher_type]
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg [key_cipher_type] [...]
debug2: input_userauth_pk_ok: fp
xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
debug1: key_load_private_type: incorrect passphrase supplied to decrypt
private key
Enter passphrase for key '~/.ssh/[key_cipher_type]':
debug1: Authentication succeeded (publickey).
--
I had to type the correct passphrase. Something is going wrong, your
doubts are confirmed. I still have to check the fingerprint. There are
three agents running after logging into my "local ssh account" and
executing
pgrep -lf ssh-agent
Two running under another user account and the one running under my
"local ssh account" (i.e. from where I establish ssh connection to the
remote server)
*BUT*
me@localsshaccount:~$ ssh-add -L
Could not open a connection to your authentication agent


Well, it's late and I will further investigate it tomorrow, but any
comments on how to make sure that ssh-agent selects the correct
passphrase/private key (automatically) appreciated.

Cheers
Stephan



Re: Issues with SSH pubkey authentication at remote server

2016-09-26 Thread Stephan Beck
Hi Mark,

Mark Fletcher:
> On Mon, 26 Sep 2016 at 19:22, Stephan Beck <sb...@secure.mailbox.org> wrote:
> 

>> If I'm reading the above right, it looks like the server is offering an
> rsa key to authenticate itself, but won't accept rsa to authenticate the
> client. Which is a bit cheeky.
> 
> You may need a key created with a stronger method, such as ecdsa or
> ed25519.

Thanks. You may be more experienced than me interpreting the ssh
communication.
Which are the signs/symbols that tell one that this line corresponds to
what the server says whereas that other line is the client's turn. Are
there any or is it just experience/contextual heuristics?

Thanks for the key cipher's advice. Maybe I should use that elliptic
curve one, as it is the latest on the scene and is stronger.

Cheers,

Stephan



Re: Issues with SSH pubkey authentication at remote server

2016-09-26 Thread Stephan Beck
Hi Lisi,

Lisi Reisz:
> On Monday 26 September 2016 12:48:00 Stephan Beck wrote:
>> Well, I better rephrase because that was a bit misleading!
>>
>> I pray for the OpenSSH package being patched
>> soon in Jessie with respect to its OpenSSL component!
> 
> Could you explain why "openssl regression update" is not at least 
> part 
> of the OpenSSL component?  (Though I can see it might be the wrong bit of the 
> component, and not what you were meaning.)
> 

If you look at the second line of the terminal output I reproduced, you
find that the openssl component in use within the package openssh Debian
Jessie is one step behind. "Standalone" OpenSSL package is now at
version 1.0.1t-1+deb8u5 since September 23.

> me@mymachine:~/.ssh$ ssh -vv me@theremoteserver
> OpenSSH_6.7p1 Debian-5+deb8u3, OpenSSL 1.0.1t  3 May 2016

Cheers,

Stephan



Re: Issues with SSH pubkey authentication at remote server

2016-09-26 Thread Stephan Beck
Hi Lars,

Lars Noodén:
> On 09/26/2016 01:18 PM, Stephan Beck wrote:
>> ...
>> Before establishing connection for the first time I did
>>
>> eval $(ssh-agent)
>> PID 
>> ssh-add ~/.ssh/id_rsa
>>
>> But it seems that the ssh-agent does not really authenticates to the
>> remote server and as a fallback password auth is selected. (I anonymized
>> the output below.) So, pubkey authentication is not working :-(
> 
> Are you running the SSH client in the same shell as you have run eval?
> Also, the desktop environment is often set up so that it is launched
> under an agent already.  So how many agents do you have running?
> 
>   pgrep -lf ssh-agent

I made sure that only one ssh-agent was running (under this user
account) by using top package and killing one more that ran with the
same account's user rights. So, I guess you were right, that it might
not be necessary to fire it up with eval $(ssh-agent).
Thanks for the command, makes it more easy.

Cheers,

Stephan



Re: Issues with SSH pubkey authentication at remote server

2016-09-26 Thread Stephan Beck
Hi,

Dan Purgert:
> Mark Fletcher wrote:
>> If I'm reading the above right, it looks like the server is offering an
>> rsa key to authenticate itself, but won't accept rsa to authenticate the
>> client. Which is a bit cheeky.
> 
>> You may need a key created with a stronger method, such as ecdsa or
>> ed25519.
> 
> Could even be as simple as he sent a /different/ key across (e.g. he
> sent "home-key.pub", which corresponds to "home-key_rsa" rather than
> "id_rsa").
> 
No. I wrote that I /checked/ the public key copied to the server after
having copied it to the server's ~/.ssh directory. I edited it with a
text editor and compared it with the one I have in local ~/.ssh

Cheers,

Stephan



Re: Issues with SSH pubkey authentication at remote server

2016-09-26 Thread Stephan Beck
Well, I better rephrase because that was a bit misleading!

I pray for the OpenSSH package being patched
soon in Jessie with respect to its OpenSSL component!


Lisi Reisz:
> On Monday 26 September 2016 11:18:00 Stephan Beck wrote:
> [snip]
>> NOTE: I pray for the OpenSSL version OpenSSH ships with being patched
>> soon in Jessie!
> 
> Is this what you are meaning?
> https://lists.debian.org/msgid-search/e1bnwuv-000727...@master.debian.org

Cheers,

Stephan



Issues with SSH pubkey authentication at remote server

2016-09-26 Thread Stephan Beck
Hi,

I have successfully uploaded my SSH public key to the authorized_keys
file in ~/.ssh on the remote server using ssh-copy-id. I connected using
password authentication to check whether it really is the correct key
there and it is. Permissions are ok.

Public key authentication is the first (in order and priority) of
several auth methods that the server offers. But as to the output below
something is not working with the submission of the secret part of the
key (well, the proof of being in possession of it) by the ssh-agent.
Before establishing connection for the first time I did

eval $(ssh-agent)
PID 
ssh-add ~/.ssh/id_rsa

But it seems that the ssh-agent does not really authenticates to the
remote server and as a fallback password auth is selected. (I anonymized
the output below.) So, pubkey authentication is not working :-(

Can anyone tell me what's going wrong, especially this
debug1: Offering RSA public key: ~/.ssh/id_rsa
debug2: we sent a publickey packet, wait for reply
...
debug2: we did not send a packet, disable method

Any hints welcome.


Stephan

---
me@mymachine:~/.ssh$ ssh -vv me@theremoteserver
OpenSSH_6.7p1 Debian-5+deb8u3, OpenSSL 1.0.1t  3 May 2016
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to theremoteserver [IPaddress_remoteserver] port 22.
debug1: Connection established.
[debug messages concerning type 1 keys, snipped]
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.7p1 Debian-5+deb8u3
debug1: Remote protocol version 2.0, remote software version
OpenSSH_6.0p1 Debian-4+deb7u6
debug1: match: OpenSSH_6.0p1 Debian-4+deb7u6 pat OpenSSH* compat 0x0400
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
[debug messages concerning ciphers, snipped]
debug1: Server host key: RSA [server_host_key]
debug1: Host 'theremoteserver' is known and matches the RSA host key.
debug1: Found key in ~/.ssh/known_hosts:4
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: ~/.ssh/id_rsa (0x1cpt789b66z1),
debug2: key: ~/.ssh/id_dsa ((nil)),
debug2: key: ~/.ssh/id_ecdsa ((nil)),
debug2: key: ~/.ssh/id_ed25519 ((nil)),
debug1: Authentications that can continue:
publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering RSA public key: ~/.ssh/id_rsa
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue:
publickey,password,keyboard-interactive
debug1: Trying private key: ~/.ssh/id_dsa
debug1: Trying private key: ~/.ssh/id_ecdsa
debug1: Trying private key: ~/.ssh/id_ed25519
debug2: we did not send a packet, disable method
debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
debug2: we sent a keyboard-interactive packet, wait for reply
debug2: input_userauth_info_req
debug2: input_userauth_info_req: num_prompts 1
Password:


NOTE: I pray for the OpenSSL version OpenSSH ships with being patched
soon in Jessie!



Re: sending authorized_keys to localhost from an account being created with adduser --disabled-password [was] Re: Need a tutorial

2016-09-23 Thread Stephan Beck
Hi Greg and Tomás (one mail for all to limit the load of this thread on
the list) :-)

Greg Wooledge:
> On Fri, Sep 23, 2016 at 12:31:00PM +0000, Stephan Beck wrote:
[...]
> As user root:
> 
> stephan@hostname:~$ sudo mkdir -p ~test/.ssh
> stephan@hostname:~$ sudo sh -c 'cat ~stephan/.ssh/id_rsa.pub >> 
> ~test/.ssh/authorized_keys'
> stephan@hostname:~$ sudo chown test ~test/.ssh ~test/.ssh/authorized_keys
> stephan@hostname:~$ sudo chmod 700 ~test/.ssh
> stephan@hostname:~$ sudo chmod 600 ~test/.ssh/authorized_keys
I only had to perform command #2, and I ran it from a root shell.
I did the connection test, and it worked fine, but only after
an ssh restart.
Without it, the output was "Permission denied (publickey)"
Command #1 wasn't necessary as ~/test/.ssh had automatically been
created when running ssh-keygen. The permission had already been changed
to its secure values. At least, I came across dash's manpage while
trying to understand what the command actually does! Thanks a lot.

> to...@tuxteam.de:

> You cannot log into test without superpowers, but you have to modify its
> ~/.ssh/authorized_keys. That means you *need* superpowers. For example
> 
>   sudo -s # or similar
>   cat ~steph/.ssh/id_rsa.pub >> ~/test/.ssh/authorized_keys
>   chown test:test ~/test/.ssh/authorized_keys
>   exit

Ran command #2 from a root shell, did the connection test and it worked,
without having to restart ssh.

By the way, when I logged in via ssh (to *test*) now I was greeted by
"Last login [time of my connection attempt]from localhost". So, I
understand that I had logged into *test* via su - test  and then had
connected to *test* (from *test*) via localhost using ssh! Is this
interpretation correct?

Thanks to both of you again.

Stephan



Re: sending authorized_keys to localhost from an account being created with adduser --disabled-password [was] Re: Need a tutorial

2016-09-23 Thread Stephan Beck
Thank you very much, Tomás.

to...@tuxteam.de:
> On Fri, Sep 23, 2016 at 12:31:00PM +0000, Stephan Beck wrote:
>> Hi
>> to...@tuxteam.de:
>>> On Thu, Sep 22, 2016 at 03:35:00PM +, Stephan Beck wrote:
[...]
>> I have created a new user account with
>> adduser --disabled-password
>> What do I want to do?
>> I'd like to login to this account "test" from my normal user account by
>> ssh via pubkey authentication. My (normal) user account has its keys
>> generated and properly deposited on localhost. I logged into the account
>> "test" via su - test, creating a keypair. Fine.
> 
> Hang on: your new account (test( doesn't need a keypair. It's your regular
> account which needs one (and has one already). You want to log in *from*
> your regular account (let's call it "seph" for now) *to* test, right?

There are two things here: I had in mind to login from my user account
via ssh to the test account (just to be able to (completely) ssh inside
my machine [for training purposes] and, on the other hand, to ssh
towards the outside (see next sentence) as well. As to the "outside"
part, from the test account I want to login as client to a remote server
and because of that this test account needs a key pair, too. Yes, I know
it has to be deposited on that server, but, again, at the moment of this
thread I still am with (setting up) sshing inside my machine.
> 
> Then it's *steph* who has to have a keypair and *test* who has to have
> *steph*'s public key included in its ~/.ssh/authorized_keys:
> 
> 
>  *steph* *test*
>  .ssh/ .ssh/
>id_rsaauthorized_keys
>id_rsa.pub  ^
>\   |
> -- add ---´
> 
> 
> The background is that now *steph* can prove to *test* that he has the
> right secret key (without disclosing it).

OK, I got it, concerning sshing inside my machine. I got confused here
as I remembered that when I had a normal user account (with wheezy) and
a chroot environment (with debian sid installed) on the same machine I
could login from one to the other and vice versa via localhost using ssh
(well, if I remember correctly). It's different, for sure, but it
confused me.
> 
[...]
> You cannot log into test without superpowers, but you have to modify its
> ~/.ssh/authorized_keys. That means you *need* superpowers. For example
> 
>   sudo -s # or similar
>   cat ~steph/.ssh/id_rsa.pub >> ~/test/.ssh/authorized_keys
>   chown test:test ~/test/.ssh/authorized_keys
>   exit

But once my user's (in your terminology, steph's) public key is in the
test account's authorized_keys file, user steph can login without
superpowers, by presenting the private part of the key (well ssh-agent
does it, if I understand things correctly), can't I?
My great mistake was to think that localhost, although being on the same
machine, acts as a somewhat separated server and for that reason the
public keys of all users have to be deposited physically, in a sort of
directory structure within localhost (not in the user's directory),as it
is the case on a remote server. But, as Greg made very clear, I'm
already on the same machine. That was the conceptual mistake I made.
> 
> (the chown just in case authorized_keys didn't exist before).

Well, I have, i.e. had created an authorized_keys with the dd command.
It's there and it contains the public key.
> 
[,,,]
> Either you give this new user a password (temporarily) or you have to
> be able to write to its .ssh directory by other means. One of those
> means is by becoming root (as sketched above). There are others, like
> 
>   - adding yourself to this new user's group and making sure
> its ~/.ssh/authorized_keys is group writable (feels somewhat
> uncomfortable, though)

Uh! No way.
> 
>   - creating the user's home directory from a prepared skeleton
> already containing an "authorized_keys" as you need it

Ah, that would be fine, but I guess, this time it has to be the hard
way, by typing, without prepared skeletons.

I have to make a break and then I will try to get it done.

Thanks again.

Stephan



Re: sending authorized_keys to localhost from an account being created with adduser --disabled-password [was] Re: Need a tutorial

2016-09-23 Thread Stephan Beck


Stephan Beck:
> Thanks, Greg. I trimmed your message just to let you know that it does
> not work.


To be clear: after having found my solution I did your test (only the
test reproduced at the end of your message) and my solution does not work.

Thanks
Stephan



Re: sending authorized_keys to localhost from an account being created with adduser --disabled-password [was] Re: Need a tutorial

2016-09-23 Thread Stephan Beck
Thanks, Greg. I trimmed your message just to let you know that it does
not work.

Greg Wooledge:
> On Fri, Sep 23, 2016 at 12:31:00PM +0000, Stephan Beck wrote:

> As user stephan, to test that it works:
> 
> stephan@hostname:~$ ssh test@localhost id
> 
> If your username isn't actually "stephan", substitute accordingly.


me@mymachine:~$ sudo service ssh restart
me@mymachine:~$ ssh xb1158@localhost id
Permission denied (publickey).

I now will read carefully your (and the other messages sent in reply)
and will give a more thorough reply in a while. When I send my messages,
I send them and do not read the answers (arrived in the meantime) first,
so please do not think that I'm not interested in them.

Many thanks.

Stephan



Re: RESOLVED Re: sending authorized_keys to localhost from an account being created with adduser --disabled-password [was] Re: Need a tutorial

2016-09-23 Thread Stephan Beck
Hi,

Stephan Beck:
> Hi
> 
> Stephan Beck:
>> Hi
>>
>> to...@tuxteam.de:
>>> On Thu, Sep 22, 2016 at 03:35:00PM +, Stephan Beck wrote:
>>>
>>>
> 
>> How do I get this public key onto localhost?
> 
> No need to reply, I'll send the answer to document my solution within
> minutes.

Solution (feel free to comment)

#setting password authentication to no
root@mymachine nano /etc/ssh/sshd_config
root@mymachine:~# su - test
test@mymachine:~/.ssh$ chmod 600 authorized_keys
test@mymachine:~/.ssh$ dd if=id_rsa.pub of=authorized_keys
[test@mymachine:~/.ssh$ ssh localhost 'cat >> .ssh/authorized_keys']
test@mymachine:~/.ssh$ ssh -v test@localhost
[..many debug1 messages]
Enter passphrase for key /home/test/.ssh/id_rsa.pub':
debug1: Authentication succeeded (publickey).
Authenticated to localhost ([127.0.0.1]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessi...@openssh.com
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = de_DE.UTF-8

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
test@mymachine:~$


I think the one put in square brackets by me is redundant, isn't it? I
remember that the system hung for a moment and I did a CTRL-C to abort,
and proceeded with the next command, and then always used the -v option.
How did I find it? I remembered that somewhere in the manpages (not
sure) there was a reference to better make use of dd to copy, and I just
tried.

Have a nice weekend!

Stephan



RESOLVED Re: sending authorized_keys to localhost from an account being created with adduser --disabled-password [was] Re: Need a tutorial

2016-09-23 Thread Stephan Beck
Hi

Stephan Beck:
> Hi
> 
> to...@tuxteam.de:
>> On Thu, Sep 22, 2016 at 03:35:00PM +0000, Stephan Beck wrote:
>>
>>

> How do I get this public key onto localhost?

No need to reply, I'll send the answer to document my solution within
minutes.


Stephan



sending authorized_keys to localhost from an account being created with adduser --disabled-password [was] Re: Need a tutorial

2016-09-23 Thread Stephan Beck
Hi

to...@tuxteam.de:
> On Thu, Sep 22, 2016 at 03:35:00PM +0000, Stephan Beck wrote:
> 
> 
>> to...@tuxteam.de:
> 
> [mumble]
> 
>>> This is the bird's view. Ask if you get stuck.
> 
> 
>> Sorry, Tomas, it's not Gene, it's me who has a special question
> 
> No need to be sorry :-)

Fine! :-)
> 
> But I see you found a solution and other chimed in with sage advice.
> 

Well, I have another one :-), a question, not a solution yet.


I have created a new user account with
adduser --disabled-password
What do I want to do?
I'd like to login to this account "test" from my normal user account by
ssh via pubkey authentication. My (normal) user account has its keys
generated and properly deposited on localhost. I logged into the account
"test" via su - test, creating a keypair. Fine.

How do I get this public key onto localhost?
I mean, I can create an authorized_keys file manually, copying the
public key into this authorized_keys file, but it's still in the user's
directory where it has been generated, it needs to be sent (or get
somehow) to localhost.

I have tried:
test@mymachine cat .ssh/id_rsa.pub | ssh localhost 'cat >>
.ssh/authorized_keys'

But it's asking me a password. There is none.
If I disable Password Authentication in sshd_config, and then try to
send it to localhost, it fails with something like "denied access
publickey required". No mystery at all, because this very public key is
being sent to localhost in this very moment and can't be used in the
same act for authentication purposes.

I've been reading a bunch of related docs in the man pages, debian wiki,
in the exquisite and very readable Debian Administrator's Handbook by
Raphael Mas and Raphaël Hertzog, and other linux ssh documentation. I
can't find my specific use case and I'm stuck.

Any hints (also from other people) welcome.

Stephan

on Debian-Jessie



Re: Need a tutorial

2016-09-22 Thread Stephan Beck
Hi,

Thomas Schmitt:
> Hi,
> 
> Greg Wooledge wrote:
>> From whichever shell he was using to
>> run adduser, he should also be able to run sudo -u test bash.
> 
> Ah yes. This works. (One just has to accomodate to the idea of the
> superuser running sudo ...)

Yes, Greg and Thomas, I've just tried

sudo -u test bash

and it definitely works.

Thanks

Stephan



Re: Need a tutorial

2016-09-22 Thread Stephan Beck
Hi,

Thomas Schmitt:
> Hi,
> 
> Greg Wooledge wrote:
>> From whichever shell he was using to
>> run adduser, he should also be able to run sudo -u test bash.
> 
> Ah yes. This works. (One just has to accomodate to the idea of the
> superuser running sudo ...)


Yes, Greg and Thomas, I've just tried

sudo -u test bash

and it definitely works here as well.

Thanks

Stephan



Re: Need a tutorial

2016-09-22 Thread Stephan Beck
Hi,

Thomas Schmitt:
> Hi,
> 
> Stephan Beck wrote:
>> How can you access this new account to generate an ssh key pair there?
> 
[sorry for trimming]

> Greg Wooledge wrote:
>> sudo -u test bash
> 
> Does not work for me (at least not out of the box):
> 
>   $ sudo -u test_user bash
>   [sudo] password for thomas: 
>   Sorry, user thomas is not allowed to execute '/bin/bash' as test_user on 
> [...]
>   $
> 
Yes, I was running adduser from the root console, as Greg assumed.
So, I saw/see no reason running sudo from the root console. In fact, I
put a # directly preceeding the generic SUDO (ALL) ALL etc. entry in
/etc/sudoers, granting determined rights only to specific users. (I
don't know if this affects sudo's overall behaviour). At least, it's
more work having to insert additional rights in /etc/sudoers for "test"
(in order to do a sudo), if I just want to ssh-keygen, ssh-copy-id and
then deactivate password authentication in sshd_config once again (to go
for pubkey auth).

Thanks for your additional comments.

Stephan



Re: Need a tutorial

2016-09-22 Thread Stephan Beck
Thanks, Greg.

Greg Wooledge:
> On Thu, Sep 22, 2016 at 03:35:00PM +0000, Stephan Beck wrote:
>> Sorry, Tomas, it's not Gene, it's me who has a special question
>> concerning ssh.
>> If you create a new user account ("test"), doing as root
>> adduser --disabled-password test
>>
>> How can you access this new account to generate an ssh key pair there?
> 
> Install sudo if you haven't already.  Then:
> 
> sudo -u test bash
> 
> Or if you don't want a whole shell:
> 
> sudo -u test ssh-keygen [options]
> 
> The su program is not as useful for this kind of task, because it
> insists on launching the target user's shell, which in some cases is
> not a useful interactive command shell (e.g. /bin/false).  sudo does
> not have this restriction.
> 

In my case all users have /bin/bash, so there's no problem.

Thanks.

Stephan



Re: Need a tutorial

2016-09-22 Thread Stephan Beck
I resolved it.
I have to type (as root)

su - test

and the prompt changes.

Stephan


Stephan Beck:
> 
> 
> to...@tuxteam.de:
>> On Wed, Sep 21, 2016 at 10:18:55AM -0400, Gene Heskett wrote:

> Sorry, Tomas, it's not Gene, it's me who has a special question
> concerning ssh.
> If you create a new user account ("test"), doing as root
> adduser --disabled-password test
> 
> How can you access this new account to generate an ssh key pair there?
> I cannot login to the account selecting "test" as user in the login
> screen on system startup, it's deactivated.
> I cannot try accessing it by ssh because I need to generate a key pair
> first. Could one generate a key pair for "test" from another account?
> 
> If I try
> ssh test@localhost
> ssh: connect to host localhost port 22: Connection refused
> 
> or, temporary enabling password authentication for a moment in
> sshd_config, it prompts for a password (that has never been created
> because of the --disabled-password option, see above).
> 
> Or, what am I missing?
> 
> Thanks in advance.
> 
> Stephan
> 
> I also read the doc you linked to in your other message of this thread,
> but I cannot find my use case.
> 
> 



Re: Need a tutorial

2016-09-22 Thread Stephan Beck


to...@tuxteam.de:
> On Wed, Sep 21, 2016 at 10:18:55AM -0400, Gene Heskett wrote:
>> Greetings all, Dr Klepp in particular;
> 
>> Where can I get a tut on doing the ssh keyfile login, and where can I 
>> find a tutorial that is essentialy what Dr. Klepp had me do about a year  
>> back that made these 3 commands in my rc.local file Just Work:
> 
> Basically:
> 
>  1. you need a keypair. Unless you have it already, you generate one
> with ssh-keygen. There, you have the choice to let it use the default
> file name (typically, ~/.ssh/id_rsa and ~/.ssh/id_rsa.pub or similar,
> depending on the key type) and whether you want the private key
> protected by a passphrase (recommended, but you have to unlock it
> either with ssh-add or whatever mechanism your desktop environment
> has for you).
> 
>  2. you copy the public part to the ~/.ssh/authorized_keys of the server's
> user you want to log into -- there's the handy "ssh-copy-id" for that.
> From the client
> 
> ssh-add # if not done already
> ssh-copy-id user@server # enter for one last time user's password there
> 
> This is the bird's view. Ask if you get stuck.
> 

Sorry, Tomas, it's not Gene, it's me who has a special question
concerning ssh.
If you create a new user account ("test"), doing as root
adduser --disabled-password test

How can you access this new account to generate an ssh key pair there?
I cannot login to the account selecting "test" as user in the login
screen on system startup, it's deactivated.
I cannot try accessing it by ssh because I need to generate a key pair
first. Could one generate a key pair for "test" from another account?

If I try
ssh test@localhost
ssh: connect to host localhost port 22: Connection refused

or, temporary enabling password authentication for a moment in
sshd_config, it prompts for a password (that has never been created
because of the --disabled-password option, see above).

Or, what am I missing?

Thanks in advance.

Stephan

I also read the doc you linked to in your other message of this thread,
but I cannot find my use case.



Re: SMTP relay issue with emails to specific domain

2016-09-09 Thread Stephan Beck
Hi Daniel,

Daniel Bareiro:
> 
> On 08/09/16 13:56, Daniel Bareiro wrote:
> 
>> I recently set up an relay SMTP server on a host of Digital Ocean, using
>> Debian and Postfix.
>>
>> The main reason for setting up this relay is that the cPanel VPS is
>> hosted at Godaddy, and they force everyone to send email through their
>> shared SMTP relay. As expected, that shared relay is continually being
>> flagged for spam.
>>
>> So the outgoing emails are routed through this server. Usually
>> everything worked smoothly. Mails to accounts on Google, Yahoo, Hotmail
>> and other servers are delivered. But I found a problem with a specific
>> domain:
>>
>> ---
>> Sep  7 14:36:11 smtp postfix/smtp[8036]: 5EAA520AAD:
>> to=, relay=lkeusa.com[50.87.144.56]:25], delay=13,
>> delays=0.91/0.06/6.1/5.9, dsn=5.0.0, status=bounced (host
>> lkeusa.com[50.87.144.56] said: 550-Please turn on SMTP Authentication in
>> your mail client, or login to the 550-IMAP/POP3 server before sending
>> your message.  smtp.server.com 550-[x.y.z.t]:41988 is not permitted to
>> relay through this server 550 without authentication. (in reply to RCPT
>> TO command))
>> ---
>>
>> I'm not sure why this specific domain is complaining in this way.

I think it's because it requires SMTP authentication, whereas apparently
the other servers you mention don't (mails are delivered). Have you
checked if the mail client's option mail.smtpserver.default.authMethod
is set to 0, which means there is no SMTP authentication at all. That
could explain the issue.
For a list of methods, see (1)
Looking at exim's server ready 220 response below, it does not like
people to send spam or bulk email.
The 550 return code means that the mailbox you are trying to reach can't
be found or you are lacking access rights. In your case it's the latter,
as the server response indicates.


(1) http://www.afterlogic.com/mailbee/docs/SMTP_props_AuthMethod.htm

Stephan

[...]
> 
> Well, it seems that in the absence of an MX record, Postfix uses the A
> record that it find by querying that domain and in that IP address an
> Exim server responds:
> 
> ---
> # telnet lkeusa.com 25
> Trying 50.87.144.56...
> Connected to lkeusa.com.
> Escape character is '^]'.
> 220-gator3037.hostgator.com ESMTP Exim 4.86_1 #1 Thu, 08 Sep 2016
> 12:15:19 -0500
> 220-We do not authorize the use of this system to transport unsolicited,
> 220 and/or bulk e-mail.
> ---
> 



Re: [xfce] - power management

2016-09-06 Thread Stephan Beck
Hi Herbert,

I don't have XFCE installed, and I don't have a solution to your problem
right now, but have you checked if your /etc/systemd/logind.conf file
has the option #HandleHibernateKey=hibernate uncommented?

Does your window manager handle this type of ACPI event(s) now?
/usr/bin/xfce4-power-manager

Does acpid handle those events? Check the scripts in /etc/acpid/events
and section Troubleshooting on acpid's man page.

Stephan

Herbert Fortes:
> Hi,
> 
> I switched from gnome to xfce because the notebook
> can not run gnome and pycharm at the same time.
> 
> I am facing problems with power management. Suspend
> works is I click on the button. Hibernate does not
> seems to work properly because I see a lot of 'OK'
> when I notebook wakes up.
> 
> 
> I tried to config policykit without success. I put a
> .pkla file in /etc/polkit-1/localauthority/50-local.d/
> about suspend and hibernate:
> 
> Identity=unix-user:*
> Action=org.freedesktop.X.X
> ResultActive=yes
> 
> X can be upower|login1 and suspend|hibernate. The
> message asking a password says login1.
> 
> I also tried putting a file in /usr/share/polkit-1/rules.d/
> with:
> 
> polkit.addRule(function(action, subject) {
> if (action.id == "org.freedesktop.login1.suspend" ||
> action.id == "org.freedesktop.login1.suspend-multiple-sessions" ||
> action.id == "org.freedesktop.login1.hibernate" ||
> action.id == "org.freedesktop.login1.hibernate-multiple-sessions")
> {
> return polkit.Result.YES;
> }
> });
> 
> 
> # Debian Testing
> $ pkaction --version
> pkaction version 0.105
> 
> 
> If someone can help me please Cc me because I am
> not on the list.
> 
> 
> 
> Regards,
> Herbert
> 
> 



Re: [xfce] - power management

2016-09-06 Thread Stephan Beck
Hi Herbert,

I don't have XFCE installed, and I don't have a solution to your problem
right now, but have you checked if your /etc/systemd/logind.conf file
has the option #HandleHibernateKey=hibernate uncommented?

Does your window manager handle this type of ACPI event(s) now?
/usr/bin/xfce4-power-manager

Does acpid handle those events? Check the scripts in /etc/acpid/events
and section Troubleshooting on acpid's man page.

Stephan


Herbert Fortes:
> Hi,
> 
> I switched from gnome to xfce because the notebook
> can not run gnome and pycharm at the same time.
> 
> I am facing problems with power management. Suspend
> works is I click on the button. Hibernate does not
> seems to work properly because I see a lot of 'OK'
> when I notebook wakes up.
> 
> 
> I tried to config policykit without success. I put a
> .pkla file in /etc/polkit-1/localauthority/50-local.d/
> about suspend and hibernate:
> 
> Identity=unix-user:*
> Action=org.freedesktop.X.X
> ResultActive=yes
> 
> X can be upower|login1 and suspend|hibernate. The
> message asking a password says login1.
> 
> I also tried putting a file in /usr/share/polkit-1/rules.d/
> with:
> 
> polkit.addRule(function(action, subject) {
> if (action.id == "org.freedesktop.login1.suspend" ||
> action.id == "org.freedesktop.login1.suspend-multiple-sessions" ||
> action.id == "org.freedesktop.login1.hibernate" ||
> action.id == "org.freedesktop.login1.hibernate-multiple-sessions")
> {
> return polkit.Result.YES;
> }
> });
> 
> 
> # Debian Testing
> $ pkaction --version
> pkaction version 0.105
> 
> 
> If someone can help me please Cc me because I am
> not on the list.
> 
> 
> 
> Regards,
> Herbert
> 
>