Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Preseeded setting on openssh-server ignored
196 views
Skip to first unread message
Murukesh Mohanan
Jun 7, 2014, 2:10:02 PM6/7/14
to
Hi,
I'm trying to use preseeding to automate installation, and
openssh-server is ignoring a selection
openssh-server openssh-server/permit-root-login bool true
The sshd_config always contains
PermitRootLogin without-password
I gather that this is due to the fix of bug #298138. While the
OP's, and the patch submitter's rationale behind changing
PermitRootLogin to without-password is ok, doing so by totally
ignoring the debconf selection if not upgrading is *not*. If I
wish to automate new installs, with a reasonably secure root
password, unlike OP, I fail to see why my preseed debconf
selection should not work. It is, after all, an explicit user
choice. There are plenty of such selections where the user is
not asked a question at all and the default selection is used,
so I fail to see why this question is being ignored (or not
asked, as maybe the case). I have no problems with the default
value being 'without-password'. But is ignoring the debconf
selection altogether the new intended behaviour, or has the
set of valid values for this selection changed?
The bug has been archived, so I'm posting to the general list
instead of to the bug itself. I have tested this out on jessie
and Ubuntu 14.04.
--
Murukesh Mohanan,
62, Hostel 5,
MTech1 CSE, RA Sysad
IIT Bombay
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/1402162727.3...@bro3886-debian.cse.iitb.ac.in
I'm trying to use preseeding to automate installation, and
openssh-server is ignoring a selection
openssh-server openssh-server/permit-root-login bool true
The sshd_config always contains
PermitRootLogin without-password
I gather that this is due to the fix of bug #298138. While the
OP's, and the patch submitter's rationale behind changing
PermitRootLogin to without-password is ok, doing so by totally
ignoring the debconf selection if not upgrading is *not*. If I
wish to automate new installs, with a reasonably secure root
password, unlike OP, I fail to see why my preseed debconf
selection should not work. It is, after all, an explicit user
choice. There are plenty of such selections where the user is
not asked a question at all and the default selection is used,
so I fail to see why this question is being ignored (or not
asked, as maybe the case). I have no problems with the default
value being 'without-password'. But is ignoring the debconf
selection altogether the new intended behaviour, or has the
set of valid values for this selection changed?
The bug has been archived, so I'm posting to the general list
instead of to the bug itself. I have tested this out on jessie
and Ubuntu 14.04.
--
Murukesh Mohanan,
62, Hostel 5,
MTech1 CSE, RA Sysad
IIT Bombay
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/1402162727.3...@bro3886-debian.cse.iitb.ac.in
Brian
Jun 8, 2014, 4:00:02 PM6/8/14
to
On Sat 07 Jun 2014 at 23:08:47 +0530, Murukesh Mohanan wrote:
> I'm trying to use preseeding to automate installation, and
> openssh-server is ignoring a selection
> openssh-server openssh-server/permit-root-login bool true
> The sshd_config always contains
> PermitRootLogin without-password
This is what you get with a new install of 1:6.6p1-1. It is the
> I'm trying to use preseeding to automate installation, and
> openssh-server is ignoring a selection
> openssh-server openssh-server/permit-root-login bool true
> The sshd_config always contains
> PermitRootLogin without-password
default. If is not to your liking you have to alter it afterwards.
> I gather that this is due to the fix of bug #298138. While the
> OP's, and the patch submitter's rationale behind changing
> PermitRootLogin to without-password is ok, doing so by totally
> ignoring the debconf selection if not upgrading is *not*. If I
> wish to automate new installs, with a reasonably secure root
> password, unlike OP, I fail to see why my preseed debconf
> selection should not work. It is, after all, an explicit user
> choice. There are plenty of such selections where the user is
> not asked a question at all and the default selection is used,
> so I fail to see why this question is being ignored (or not
> asked, as maybe the case). I have no problems with the default
> value being 'without-password'. But is ignoring the debconf
> selection altogether the new intended behaviour, or has the
> set of valid values for this selection changed?
>
> The bug has been archived, so I'm posting to the general list
> instead of to the bug itself. I have tested this out on jessie
> and Ubuntu 14.04.
1:6.6p1-1. README.Debian has details of the change.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Brian
Jun 8, 2014, 5:20:01 PM6/8/14
to
On Sun 08 Jun 2014 at 20:55:19 +0100, Brian wrote:
> This is what you get with a new install of 1:6.6p1-1. It is the
> default. If is not to your liking you have to alter it afterwards.
Or deal with it with late_command in your preseed file.
> This is what you get with a new install of 1:6.6p1-1. It is the
> default. If is not to your liking you have to alter it afterwards.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Murukesh Mohanan
Jun 9, 2014, 6:10:03 PM6/9/14
to
A few points:
1. I have explicitly stated that I am automating new installations.
I don't understand what repeating that statement back to me means.
I have read README.Debian, and I don't see how it answers my question,
which is: *why* are you totally ignoring a user-made selection of
pre-exisitng debconf question, _irrespective_ of whether it's an upgrade
or a new installation? If some ignoramus sets a weak password and get's
exploited, because of a old default, I don't see why it should become my
problem or yours. The Debian maintainers can set whatever default they
chose to, as is their right, but why make a decision to ignore the
user's right to change that default from a pre-existing method? If you
are going to do so, then why haven't you stated that in the
root-forsaken README.Debian? I've seen uses of this selection for
enabling login with password from at least over a year ago, so I am not
hallucinating about this. /rant
Sorry for that.
2. Wouldn't the right way to make this change be either a) using a
select field instead of a boolean or b) treating true as "yes", *and*
respecting this selection (assuming debconf has a way of notifying if
no value is set), instead of ignoring it?
3. If I made a patch to implement 2a or 2b, and it is not crap, would
you accept it? Or is this a hard setting on the side of Debian
maintainers?
--
Murukesh Mohanan
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/53962CC...@cse.iitb.ac.in
1. I have explicitly stated that I am automating new installations.
I don't understand what repeating that statement back to me means.
I have read README.Debian, and I don't see how it answers my question,
which is: *why* are you totally ignoring a user-made selection of
pre-exisitng debconf question, _irrespective_ of whether it's an upgrade
or a new installation? If some ignoramus sets a weak password and get's
exploited, because of a old default, I don't see why it should become my
problem or yours. The Debian maintainers can set whatever default they
chose to, as is their right, but why make a decision to ignore the
user's right to change that default from a pre-existing method? If you
are going to do so, then why haven't you stated that in the
root-forsaken README.Debian? I've seen uses of this selection for
enabling login with password from at least over a year ago, so I am not
hallucinating about this. /rant
Sorry for that.
2. Wouldn't the right way to make this change be either a) using a
select field instead of a boolean or b) treating true as "yes", *and*
respecting this selection (assuming debconf has a way of notifying if
no value is set), instead of ignoring it?
3. If I made a patch to implement 2a or 2b, and it is not crap, would
you accept it? Or is this a hard setting on the side of Debian
maintainers?
--
Murukesh Mohanan
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Murukesh Mohanan
Jun 9, 2014, 6:20:04 PM6/9/14
to
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/53962D9E...@cse.iitb.ac.in
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Bob Proulx
Jun 12, 2014, 6:20:02 PM6/12/14
to
Murukesh Mohanan wrote:
> 1. I have explicitly stated that I am automating new installations.
> I don't understand what repeating that statement back to me means.
> I have read README.Debian, and I don't see how it answers my question,
> which is: *why* are you totally ignoring a user-made selection of
> pre-exisitng debconf question, _irrespective_ of whether it's an upgrade
> or a new installation?
It appears to me that this is simply a misunderstanding. Let me
> 1. I have explicitly stated that I am automating new installations.
> I don't understand what repeating that statement back to me means.
> I have read README.Debian, and I don't see how it answers my question,
> which is: *why* are you totally ignoring a user-made selection of
> pre-exisitng debconf question, _irrespective_ of whether it's an upgrade
> or a new installation?
review. You asked about the /etc/ssh/sshd_config PermitRootLogin
variable setting. Brian replied that was the default package value
upon installation and that the default value had changed and that this
was documented in the /usr/share/doc/openssh-server/README.Debian.gz
file. The package maintainer documented the change to the default
value. There is a lot of good information there and I don't want to
distract from it. Please read through the discussion about why they
decided to make the change. (Personally I would rather have a
different default setting but I am happy that the discussion was
documented and I can respect the result and deal with it.
By default installation it means that if no openssh-server package is
installed then there won't be a /etc/ssh/sshd_config file. When the
package is installed it will place a default sshd_config file there
and that file previously contained:
PermitRootLogin yes
In new installations that file will contain:
PermitRootLogin without-password
If you have an existing installation then the file will already exist
with the previous value. That is why it is different depending upon
whether it is a new installation or an upgraded one.
> If some ignoramus sets a weak password and get's exploited, because
> of a old default, I don't see why it should become my problem or
> yours. The Debian maintainers can set whatever default they chose
> to, as is their right, but why make a decision to ignore the user's
> right to change that default from a pre-existing method?
talking about. Sorry.
> If you are going to do so, then why haven't you stated that in the
> root-forsaken README.Debian? I've seen uses of this selection for
> enabling login with password from at least over a year ago, so I am
> not hallucinating about this. /rant Sorry for that.
> I'm trying to use preseeding to automate installation, and
> openssh-server is ignoring a selection
> openssh-server openssh-server/permit-root-login bool true
that construct as a preseed. Where is that documented? Does it
actually exist? (I don't have the time to try it to find out.)
I think that is the root of the confusion. You are trying to use the
above as a preseed but I don't find where that would be a documented
preseed interface. Please educate me if it is actually documented
anywhere.
Since I can't find it I can only assume that is where the issue lies.
It isn't a preseed. You can't set that option at install time with a
preseed. I know that was Brian's expectation too because Brian
suggested the option of using late_command in your preseed file and
setting up a late_command to make the config file change to
sshd_config so that it would be the value you want. And that would be
my recommendation too.
> 2. Wouldn't the right way to make this change be either a) using a
> select field instead of a boolean or b) treating true as "yes", *and*
> respecting this selection (assuming debconf has a way of notifying if
> no value is set), instead of ignoring it?
a documented interface then no.
> 3. If I made a patch to implement 2a or 2b, and it is not crap, would
> you accept it? Or is this a hard setting on the side of Debian
> maintainers?
maintainers of the openssh package. That package is a team maintained
package by the debian-ssh team. You would need to contact them. I
don't think anyone here will know if any of those folks are subscribed
to the debian-user mailing list. The debian-user mailing list is a
community support mailing list. We are all simply users here and try
to help each other out.
Bob
Murukesh Mohanan
Jun 13, 2014, 2:30:02 PM6/13/14
to
> > If some ignoramus sets a weak password and get's exploited, because
> > of a old default, I don't see why it should become my problem or
> > yours. The Debian maintainers can set whatever default they chose
> > to, as is their right, but why make a decision to ignore the user's
> > right to change that default from a pre-existing method?
>
> I read through this several times and I have no idea what you are
> talking about. Sorry.
That's about the bug report that led to all this:
> > of a old default, I don't see why it should become my problem or
> > yours. The Debian maintainers can set whatever default they chose
> > to, as is their right, but why make a decision to ignore the user's
> > right to change that default from a pre-existing method?
>
> I read through this several times and I have no idea what you are
> talking about. Sorry.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=298138
>
> > If you are going to do so, then why haven't you stated that in the
> > root-forsaken README.Debian? I've seen uses of this selection for
> > enabling login with password from at least over a year ago, so I am
> > not hallucinating about this. /rant Sorry for that.
>
> I think you must be referring to this from your original message.
>
> > I'm trying to use preseeding to automate installation, and
> > openssh-server is ignoring a selection
> > openssh-server openssh-server/permit-root-login bool true
>
> Huh? What? Huh? I can find no documentation supporting the use of
> that construct as a preseed. Where is that documented? Does it
> actually exist? (I don't have the time to try it to find out.)
> I think that is the root of the confusion. You are trying to use the
> above as a preseed but I don't find where that would be a documented
> preseed interface. Please educate me if it is actually documented
> anywhere.
>
> Since I can't find it I can only assume that is where the issue lies.
> It isn't a preseed. You can't set that option at install time with a
> preseed. I know that was Brian's expectation too because Brian
> suggested the option of using late_command in your preseed file and
> setting up a late_command to make the config file change to
> sshd_config so that it would be the value you want. And that would be
> my recommendation too.
anywhere, except for the standard debian installer values given in
Debian's and Ubuntu's example preseed files. I found this preseed option
in forum postings somewhere.
My current method, replacing the entire sshd_config, seems a better
option to me than a scripted change in late_command, given that it's not
the only config file I have to change.. I'll stick to that until/unless
I can get a fix to this.
>
> > 2. Wouldn't the right way to make this change be either a) using a
> > select field instead of a boolean or b) treating true as "yes", *and*
> > respecting this selection (assuming debconf has a way of notifying if
> > no value is set), instead of ignoring it?
>
> Assuming this is a documented interface, then okay. But if it isn't
> a documented interface then no.
documented anywhere?
>
> > 3. If I made a patch to implement 2a or 2b, and it is not crap, would
> > you accept it? Or is this a hard setting on the side of Debian
> > maintainers?
>
> Whether this is accepted in the Debian package is up to the Debain
> maintainers of the openssh package. That package is a team maintained
> package by the debian-ssh team. You would need to contact them. I
> don't think anyone here will know if any of those folks are subscribed
> to the debian-user mailing list. The debian-user mailing list is a
> community support mailing list. We are all simply users here and try
> to help each other out.
>
Thanks. I will perhaps open a new bug report or contact them some other
way. Sorry for the trouble.
> Bob
--
Murukesh Mohanan
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Bob Proulx
Jun 13, 2014, 4:30:02 PM6/13/14
to
Murukesh Mohanan wrote:
README.Debian.gz file that Brian and I referenced.
Personally I always use a strong password for root, only very rarely
log in as root using a password, mostly use ssh rsa keys with a strong
passphrase for remotely logging in, but do allow remote root login.
Sometimes only root can log into the system. Blocking that prevents
saving the machine in those bad situations. I don't relish a several
hour flight/drive to get hands-on physical access to a system which
would be only the alternative. Since I am confident that my strong
root password is sufficiently difficult to exploit it is a good
configuration for me to allow remote root login to be able to save the
machine in those times when only root can log in and it needs saving.
I know that others feel differently and that is fine for them.
Certainly if it is your own laptop then you always have physical
access so it doesn't matter what you choose. There isn't a one size
fits all configuration for everyone. Just a default until you need to
customize it. If everyone must always customize it then I don't think
it is a reasonable default. If it works for most people then that is
about as good as it can get.
> > Assuming this is a documented interface, then okay. But if it isn't
> > a documented interface then no.
>
> Are package preseed settings, as opposed to debian-installer ones
> documented anywhere?
Not that I know of. And by that neither do I think they are available
for preseed at system installation time. I do not use *package*
preseeds myself at system installation time. I configure packages
after system installation.
If you can make it work otherwise then that is good for you. I am not
going to stand in the way of someone who is actually getting something
done. But it seems that it isn't working for you. And at this point
I think it is because it isn't expected to work that way.
> > Whether this is accepted in the Debian package is up to the Debain
> > maintainers of the openssh package. That package is a team maintained
> > package by the debian-ssh team. You would need to contact them. I
> > don't think anyone here will know if any of those folks are subscribed
> > to the debian-user mailing list. The debian-user mailing list is a
> > community support mailing list. We are all simply users here and try
> > to help each other out.
>
> I would have posted to the original bug, but it's archived.
> Thanks. I will perhaps open a new bug report or contact them some other
> way. Sorry for the trouble.
Please I was happy to help with the discussion. You were on topic for
the mailing list. You are having trouble using the Debian system and
were discussing it. That is perfect for this mailing list. It just
happens to be that while this mailing is good for discussion it isn't
a place to reach a final decision. For this package that is up to the
debian-ssh team. So please feel free to discuss here and formulate
and refine the thoughts and then take the issue to the upstream team.
That's good!
Bob
> Bob Proulx wrote:
> > was documented in the /usr/share/doc/openssh-server/README.Debian.gz
>
> > was documented in the /usr/share/doc/openssh-server/README.Debian.gz
>
> That's about the bug report that led to all this:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=298138
I am familiar with that bug report. It is referenced in the
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=298138
README.Debian.gz file that Brian and I referenced.
Personally I always use a strong password for root, only very rarely
log in as root using a password, mostly use ssh rsa keys with a strong
passphrase for remotely logging in, but do allow remote root login.
Sometimes only root can log into the system. Blocking that prevents
saving the machine in those bad situations. I don't relish a several
hour flight/drive to get hands-on physical access to a system which
would be only the alternative. Since I am confident that my strong
root password is sufficiently difficult to exploit it is a good
configuration for me to allow remote root login to be able to save the
machine in those times when only root can log in and it needs saving.
I know that others feel differently and that is fine for them.
Certainly if it is your own laptop then you always have physical
access so it doesn't matter what you choose. There isn't a one size
fits all configuration for everyone. Just a default until you need to
customize it. If everyone must always customize it then I don't think
it is a reasonable default. If it works for most people then that is
about as good as it can get.
> > Assuming this is a documented interface, then okay. But if it isn't
> > a documented interface then no.
>
> Are package preseed settings, as opposed to debian-installer ones
> documented anywhere?
for preseed at system installation time. I do not use *package*
preseeds myself at system installation time. I configure packages
after system installation.
If you can make it work otherwise then that is good for you. I am not
going to stand in the way of someone who is actually getting something
done. But it seems that it isn't working for you. And at this point
I think it is because it isn't expected to work that way.
> > Whether this is accepted in the Debian package is up to the Debain
> > maintainers of the openssh package. That package is a team maintained
> > package by the debian-ssh team. You would need to contact them. I
> > don't think anyone here will know if any of those folks are subscribed
> > to the debian-user mailing list. The debian-user mailing list is a
> > community support mailing list. We are all simply users here and try
> > to help each other out.
>
> I would have posted to the original bug, but it's archived.
> Thanks. I will perhaps open a new bug report or contact them some other
> way. Sorry for the trouble.
the mailing list. You are having trouble using the Debian system and
were discussing it. That is perfect for this mailing list. It just
happens to be that while this mailing is good for discussion it isn't
a place to reach a final decision. For this package that is up to the
debian-ssh team. So please feel free to discuss here and formulate
and refine the thoughts and then take the issue to the upstream team.
That's good!
Bob
Bzzzz
Jun 13, 2014, 4:50:01 PM6/13/14
to
On Fri, 13 Jun 2014 14:25:28 -0600
Bob Proulx <b...@proulx.com> wrote:
> Personally I always use a strong password for root, only very
> rarely log in as root using a password,
> mostly use ssh rsa keys with a strong passphrase for remotely
> logging in, but do allow remote root login.
? You don't need a password (except for local login,
Bob Proulx <b...@proulx.com> wrote:
> Personally I always use a strong password for root, only very
> rarely log in as root using a password,
> mostly use ssh rsa keys with a strong passphrase for remotely
> logging in, but do allow remote root login.
œuf corse), only to record the distant root RSA key
into $HOME/.ssh/authorized_keys and allow key remote
login.
Which has been repeatedly discussed in Debian and is
sure (even for root).
--
<Plop> I just notices that my tee-shirt "Free Tibet"
was branded "made in china "-_-"
Bob Proulx
Jun 13, 2014, 5:10:01 PM6/13/14
to
Bzzzz wrote:
documented in the README.Debian file. A good default for most uses.
That is why I said "personally" in the above. It is my personal
choice. I acknowledge that others feel differently.
Just to plug a good tool I like using pwgen to generate truly random
passwords. A long random password is sufficiently difficult to
exploit. If you are using passwords that are easy to crack then they
should definitely be disabled. Here is an example:
$ pwgen 16 1
au6fiegieCh5shio
> Which has been repeatedly discussed in Debian and is
> sure (even for root).
Unless due to system breakage that fails to work right when you need
it. And then the only way in is the password. Or a long flight/drive
to get hands-on physical access to the remote machine.
For those terrified of root being able to log in then it is your
choice to disable it. Please feel free to do so. Just remember that
the only truly safe computer is one that is powered off. This next
reference is about firewalls but it feels like it can apply here too.
http://www.ranum.com/security/computer_security/papers/a1-firewall/index.html
Bob
> Bob Proulx wrote:
> > Personally I always use a strong password for root, only very
> > rarely log in as root using a password,
> > mostly use ssh rsa keys with a strong passphrase for remotely
> > logging in, but do allow remote root login.
>
> ? You don't need a password (except for local login,
> œuf corse), only to record the distant root RSA key
> into $HOME/.ssh/authorized_keys and allow key remote
> login.
Yes. That is why the new Debian default is "without-password" as
> > Personally I always use a strong password for root, only very
> > rarely log in as root using a password,
> > mostly use ssh rsa keys with a strong passphrase for remotely
> > logging in, but do allow remote root login.
>
> ? You don't need a password (except for local login,
> œuf corse), only to record the distant root RSA key
> into $HOME/.ssh/authorized_keys and allow key remote
> login.
documented in the README.Debian file. A good default for most uses.
That is why I said "personally" in the above. It is my personal
choice. I acknowledge that others feel differently.
Just to plug a good tool I like using pwgen to generate truly random
passwords. A long random password is sufficiently difficult to
exploit. If you are using passwords that are easy to crack then they
should definitely be disabled. Here is an example:
$ pwgen 16 1
au6fiegieCh5shio
> Which has been repeatedly discussed in Debian and is
> sure (even for root).
it. And then the only way in is the password. Or a long flight/drive
to get hands-on physical access to the remote machine.
For those terrified of root being able to log in then it is your
choice to disable it. Please feel free to do so. Just remember that
the only truly safe computer is one that is powered off. This next
reference is about firewalls but it feels like it can apply here too.
http://www.ranum.com/security/computer_security/papers/a1-firewall/index.html
Bob
Brian
Jun 13, 2014, 5:20:01 PM6/13/14
to
On Fri 13 Jun 2014 at 23:36:41 +0530, Murukesh Mohanan wrote:
> That's about the bug report that led to all this:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=298138
The usual complaint, I see. password1 is an insecure password for root
> That's about the bug report that led to all this:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=298138
to use so we mustn't allow root to log in via ssh.
> To date I haven't been able to find documented lists of preseeds
> anywhere, except for the standard debian installer values given in
> Debian's and Ubuntu's example preseed files. I found this preseed option
> in forum postings somewhere.
but please would you quote this option so we know what you are talking
about?
I can categorically state there is no preseed option for permit-root-login
in Wheezy, Squeeze or Lenny.
> My current method, replacing the entire sshd_config, seems a better
> option to me than a scripted change in late_command, given that it's not
> the only config file I have to change.. I'll stick to that until/unless
> I can get a fix to this.
the problem?
> Are package preseed settings, as opposed to debian-installer ones
> documented anywhere?
package. The 'dpkg-reconfigure' command can also be a useful guide.
As a matter of interest: what does
dpkg-reconfigure openssh-server
display?
> I would have posted to the original bug, but it's archived.
> Thanks. I will perhaps open a new bug report or contact them some other
> way. Sorry for the trouble.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Brian
Jun 13, 2014, 5:30:02 PM6/13/14
to
On Fri 13 Jun 2014 at 22:42:49 +0200, Bzzzz wrote:
> On Fri, 13 Jun 2014 14:25:28 -0600
> Bob Proulx <b...@proulx.com> wrote:
>
> > Personally I always use a strong password for root, only very
> > rarely log in as root using a password,
> > mostly use ssh rsa keys with a strong passphrase for remotely
> > logging in, but do allow remote root login.
>
> ? You don't need a password (except for local login,
> œuf corse), only to record the distant root RSA key
> into $HOME/.ssh/authorized_keys and allow key remote
> login.
>
> Which has been repeatedly discussed in Debian and is
> sure (even for root).
It has cropped up on -user from time to time and the very strange view
> On Fri, 13 Jun 2014 14:25:28 -0600
> Bob Proulx <b...@proulx.com> wrote:
>
> > Personally I always use a strong password for root, only very
> > rarely log in as root using a password,
> > mostly use ssh rsa keys with a strong passphrase for remotely
> > logging in, but do allow remote root login.
>
> ? You don't need a password (except for local login,
> œuf corse), only to record the distant root RSA key
> into $HOME/.ssh/authorized_keys and allow key remote
> login.
>
> Which has been repeatedly discussed in Debian and is
> sure (even for root).
that a password login is inherently insecure is sometimes advanced.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Bzzzz
Jun 13, 2014, 6:20:02 PM6/13/14
to
On Fri, 13 Jun 2014 15:02:06 -0600
Bob Proulx <b...@proulx.com> wrote:
> Just to plug a good tool I like using pwgen to generate truly
> random passwords. A long random password is sufficiently
> difficult to exploit. If you are using passwords that are easy to
> crack then they should definitely be disabled. Here is an example:
>
> $ pwgen 16 1
> au6fiegieCh5shio
I prefer:
Bob Proulx <b...@proulx.com> wrote:
> Just to plug a good tool I like using pwgen to generate truly
> random passwords. A long random password is sufficiently
> difficult to exploit. If you are using passwords that are easy to
> crack then they should definitely be disabled. Here is an example:
>
> $ pwgen 16 1
> au6fiegieCh5shio
$ pwgen -c -C -n -s -y 16 8
=oTFM[vI,2z/U4(i 2Zz.4G-oZ:I_XH5` Dii'9$o:a;aVzv}k hy1Td!xOs^G"Yuy7
.xV40]n_ZqdyAa;i .k5^A`cV]egz:&%> f$yswrq@J=:mW2)P rc't2O3k'Ld`WH5|
:)
--
Bora dit : I can see the most used key of my keyboard: AERTIOPSDN !
Gru dit : Strangely, you can write "porno site".
Bora dit : ...
Bzzzz
Jun 13, 2014, 6:30:02 PM6/13/14
to
On Fri, 13 Jun 2014 22:28:31 +0100
Brian <ad...@cityscape.co.uk> wrote:
> It has cropped up on -user from time to time and the very strange
> view that a password login is inherently insecure is sometimes
> advanced.
Well, if you raise the time between P/W attempts to, lets say
Brian <ad...@cityscape.co.uk> wrote:
> It has cropped up on -user from time to time and the very strange
> view that a password login is inherently insecure is sometimes
> advanced.
30 seconds, it'll take _some_ (looong) time to break it ;)
--
<Thethis> why are there only girls 10 years older than me
that tell me I've got pretty eyes, nice bump, and
that I'm charming ? T_T
<Alaric> Because eyesight drops with age.
Scott Ferguson
Jun 13, 2014, 7:20:01 PM6/13/14
to
On 14/06/14 07:18, Brian wrote:
> On Fri 13 Jun 2014 at 23:36:41 +0530, Murukesh Mohanan wrote:
>
>> That's about the bug report that led to all this:
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=298138
>
> The usual complaint, I see. password1 is an insecure password for root
> to use so we mustn't allow root to log in via ssh.
I agree with Bob, for the same reasons, - no sudo, proper password
> On Fri 13 Jun 2014 at 23:36:41 +0530, Murukesh Mohanan wrote:
>
>> That's about the bug report that led to all this:
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=298138
>
> The usual complaint, I see. password1 is an insecure password for root
> to use so we mustn't allow root to log in via ssh.
management and sshkey. But no ssh root logins allowed.
(but my passwords are always at least 4 numbers).
I (now) also believe that making sudo default is a good idea - for
Keep-Hitting-The-Enter-Key installs. (like anti-boot holsters for drummers?)
>
>> To date I haven't been able to find documented lists of preseeds
>> anywhere, except for the standard debian installer values given in
>
> You haven't looked hard enough.
As is the Debian Wiki:-
https://wiki.debian.org/DebianInstaller/Preseed
>
>> Debian's and Ubuntu's example preseed files. I found this preseed option
>> in forum postings somewhere.
>
> Which preseed option? You might not be able to find the forum posting
> but please would you quote this option so we know what you are talking
> about?
>
> I can categorically state there is no preseed option for permit-root-login
> in Wheezy, Squeeze or Lenny.
permit-root-login != root-login
>> Debian's and Ubuntu's example preseed files. I found this preseed option
>> in forum postings somewhere.
>
> Which preseed option? You might not be able to find the forum posting
> but please would you quote this option so we know what you are talking
> about?
>
> I can categorically state there is no preseed option for permit-root-login
> in Wheezy, Squeeze or Lenny.
Perhaps the OP wants:-
### Users
# root
d-i passwd/root-login boolean true
user-setup-udeb passwd/root-login boolean true
d-i passwd/root-password password PasswordsROK
d-i passwd/root-password-again password PasswordsROK
# d-i passwd/root-password-crypted password
[$1$JCsRluxD$kkpKmZGw.a1YGdJfybefg.]
# $ printf "password" | mkpasswd -s -m md5
# Enable shadow passwords.
user-setup-udeb passwd/shadow boolean true
# The user's name and login.
d-i passwd/make-user boolean true
user-setup-udeb passwd/make-user boolean true
passwd passwd/user-fullname string Uncrackable
passwd passwd/username string fool
d-i passwd/user-password password SayFish
d-i passwd/user-password-again password SayFish
#d-i passwd/user-password-crypted password
[$1$kQMIgPMe$F89vPeUWX3EqnQncn9HLn.]
# user-setup-udeb user-setup/password-weak boolean false
# And other user properties
d-i passwd/user-default-groups string fool lp dialout cdrom audio dip
video plugdev users mlocate powerdev netdev fuse sambashare lpadmin scanner
d-i user-setup/encrypt-home boolean false
user-setup-udeb user-setup/encrypt-home boolean true
>
>> My current method, replacing the entire sshd_config, seems a better
>> option to me than a scripted change in late_command, given that it's not
>> the only config file I have to change.. I'll stick to that until/unless
>> I can get a fix to this.
use of preseeding?
Use httpass and https to secure your postseed download if it's not a LAN
download:-
### Finish the installation
# Avoid that last message about the install being complete.
d-i finish-install/reboot_in_progress note
# post install scripts
d-i preseed/late_command string in-target wget
http://192.168.0.2/postseed.tar.bz2; in-target tar xvfP
postseed.tar.bz2;mv something somewhere
Kind regards
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Curt
Jun 14, 2014, 5:10:01 AM6/14/14
to
On 2014-06-13, Bob Proulx <b...@proulx.com> wrote:
>
>
> Just to plug a good tool I like using pwgen to generate truly random
> passwords. A long random password is sufficiently difficult to
> exploit. If you are using passwords that are easy to crack then they
> should definitely be disabled. Here is an example:
>
> $ pwgen 16 1
> au6fiegieCh5shio
>
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=726578
>
>
> Just to plug a good tool I like using pwgen to generate truly random
> passwords. A long random password is sufficiently difficult to
> exploit. If you are using passwords that are easy to crack then they
> should definitely be disabled. Here is an example:
>
> $ pwgen 16 1
> au6fiegieCh5shio
>
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Lisi Reisz
Jun 14, 2014, 7:00:02 AM6/14/14
to
On Friday 13 June 2014 22:02:06 Bob Proulx wrote:
> Just to plug a good tool I like using pwgen to generate truly random
> passwords. A long random password is sufficiently difficult to
> exploit. If you are using passwords that are easy to crack then they
> should definitely be disabled. Here is an example:
>
> $ pwgen 16 1
> au6fiegieCh5shio
Can it be set to use anything other than alpha-numeric?
> Just to plug a good tool I like using pwgen to generate truly random
> passwords. A long random password is sufficiently difficult to
> exploit. If you are using passwords that are easy to crack then they
> should definitely be disabled. Here is an example:
>
> $ pwgen 16 1
> au6fiegieCh5shio
Lisi
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Iain M Conochie
Jun 14, 2014, 7:10:01 AM6/14/14
to
<snip>
openssh-server package? I can find 4:
openssh-server ssh/vulnerable_host_keys note
openssh-server ssh/use_old_init_script boolean true
openssh-server ssh/encrypted_host_key_but_no_keygen note
openssh-server ssh/disable_cr_auth boolean false
Do you know of any others? Where are these documented? And while we are
at it, are preseed options for each package documented in the package?
Cheers
Iain
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/539C2911...@thargoid.co.uk
>> To date I haven't been able to find documented lists of preseeds
>> anywhere, except for the standard debian installer values given in
> You haven't looked hard enough.
>
>> Debian's and Ubuntu's example preseed files. I found this preseed option
>> in forum postings somewhere.
> Which preseed option? You might not be able to find the forum posting
> but please would you quote this option so we know what you are talking
> about?
>
> I can categorically state there is no preseed option for permit-root-login
> in Wheezy, Squeeze or Lenny.
>
Can you categorically state what _are_ the preseed options for the
>> anywhere, except for the standard debian installer values given in
> You haven't looked hard enough.
>
>> Debian's and Ubuntu's example preseed files. I found this preseed option
>> in forum postings somewhere.
> Which preseed option? You might not be able to find the forum posting
> but please would you quote this option so we know what you are talking
> about?
>
> I can categorically state there is no preseed option for permit-root-login
> in Wheezy, Squeeze or Lenny.
>
openssh-server package? I can find 4:
openssh-server ssh/vulnerable_host_keys note
openssh-server ssh/use_old_init_script boolean true
openssh-server ssh/encrypted_host_key_but_no_keygen note
openssh-server ssh/disable_cr_auth boolean false
Do you know of any others? Where are these documented? And while we are
at it, are preseed options for each package documented in the package?
Cheers
Iain
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Diogene Laerce
Jun 14, 2014, 7:10:01 AM6/14/14
to
On 06/14/2014 12:57 PM, Lisi Reisz wrote:
> On Friday 13 June 2014 22:02:06 Bob Proulx wrote:
>> Just to plug a good tool I like using pwgen to generate truly random
>> passwords. A long random password is sufficiently difficult to
>> exploit. If you are using passwords that are easy to crack then they
>> should definitely be disabled. Here is an example:
>>
>> $ pwgen 16 1
>> au6fiegieCh5shio
>
> Can it be set to use anything other than alpha-numeric?
it, with pronounceable, alpha or not, special characters or not options..
Cheers :)
--
“One original thought is worth a thousand mindless quotings.”
“Le vrai n'est pas plus sûr que le probable.”
Diogene Laerce
Brian
Jun 14, 2014, 9:00:01 AM6/14/14
to
On Sat 14 Jun 2014 at 11:50:57 +0100, Iain M Conochie wrote:
> Can you categorically state what _are_ the preseed options for the
> openssh-server package? I can find 4:
The ones you listed below are for a fresh install of Wheezy. Jessie is
> Can you categorically state what _are_ the preseed options for the
> openssh-server package? I can find 4:
different. This output can be obtained from
debconf-show openssh-server
None are prefixed with an '*' so no questions have been asked.
> openssh-server ssh/vulnerable_host_keys note
> openssh-server ssh/use_old_init_script boolean true
> openssh-server ssh/encrypted_host_key_but_no_keygen note
> openssh-server ssh/disable_cr_auth boolean false
>
> Do you know of any others? Where are these documented? And while we
> are at it, are preseed options for each package documented in the
> package?
system. debconf-show gives them too.
The templates file in a package is as good a place as any to look for
preseed options and their documentation.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Don Armstrong
Jun 14, 2014, 1:10:02 PM6/14/14
to
On Sat, 14 Jun 2014, Lisi Reisz wrote:
> Can it be set to use anything other than alpha-numeric?
Yes.
> Can it be set to use anything other than alpha-numeric?
$ pwgen -sy 16 1;
Z/;fv!2B:C=^@kvH
If you just want purely random passwords, though, you might try
makepasswd instead. pwgen is more biased towards generating
distinguishable, memorable passwords instead of truly random ones.
--
Don Armstrong http://www.donarmstrong.com
It's brief and bright, dear children; bright and brief.
Delight's the lightning; the long thunder's grief.
-- John Frederick Nims "Poetry in Motion" p31
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Patrick Chkoreff
Jun 14, 2014, 2:40:02 PM6/14/14
to
Don Armstrong wrote, On 06/14/2014 01:04 PM:
> If you just want purely random passwords, though, you might try
> makepasswd instead. pwgen is more biased towards generating
> distinguishable, memorable passwords instead of truly random ones.
Here's a way to generate a *truly* random password that is *also* memorable:
> If you just want purely random passwords, though, you might try
> makepasswd instead. pwgen is more biased towards generating
> distinguishable, memorable passwords instead of truly random ones.
http://diceware.com
Instead of using your computer to generate allegedly random bits, you
use five six-sided dice to generate truly random bits.
-- Patrick
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Bzzzz
Jun 14, 2014, 3:00:01 PM6/14/14
to
On Sat, 14 Jun 2014 14:06:40 -0400
Patrick Chkoreff <pat...@rayservers.net> wrote:
> Instead of using your computer to generate allegedly random bits,
> you use five six-sided dice to generate truly random bits.
You can also eat peas and count the number of seconds
Patrick Chkoreff <pat...@rayservers.net> wrote:
> Instead of using your computer to generate allegedly random bits,
> you use five six-sided dice to generate truly random bits.
between two farts, then divide it by the captain's age.
Ok, I ->[]
--
<Chess> Hey guys, I've got a pure idea !
*aX1s play dead
*Deadpool put his head in the microwave
*Qwerty jump by the window
*Landlord dig an evasion tunnel in the floor
*Arg`tr gulp down a Prozac tube
*Planetary make himself hara-kiri with a tea spoon
<Chess> :'(
Bob Proulx
Jun 14, 2014, 3:40:02 PM6/14/14
to
Curt wrote:
that the way I am using it and proposing it to others I should add the
-s option.
Instead of:
$ pwgen 16 1
shohReeg3ceidae7
That should at least have -s instead:
$ pwgen -s 16 1
pfqePLprEjMy9D3s
However at 16 characters or more even the default options still
provide quite a bit of entropy and would be hard to exploit.
The biggest problem I have found using random passwords is that some
sites truncate the password to a shorter number of characters. Some
of those are fairly high profile sites! http://www.schwab.com/ is a
good example that truncates passwords at eight characters. There is
no defensible rationale for doing that truncation. When I see that I
assume that means that they are storing the plaintext of the password
somewhere. Otherwise if they were properly hashing the password why
would they feel the need to truncate it?
Bob
> Bob Proulx wrote:
> > Just to plug a good tool I like using pwgen to generate truly random
> > passwords. A long random password is sufficiently difficult to
> > exploit. If you are using passwords that are easy to crack then they
> > should definitely be disabled. Here is an example:
> >
> > $ pwgen 16 1
> > au6fiegieCh5shio
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=726578
That ticket is mostly an argument over defaults. But you are right
> > Just to plug a good tool I like using pwgen to generate truly random
> > passwords. A long random password is sufficiently difficult to
> > exploit. If you are using passwords that are easy to crack then they
> > should definitely be disabled. Here is an example:
> >
> > $ pwgen 16 1
> > au6fiegieCh5shio
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=726578
that the way I am using it and proposing it to others I should add the
-s option.
Instead of:
$ pwgen 16 1
shohReeg3ceidae7
That should at least have -s instead:
$ pwgen -s 16 1
pfqePLprEjMy9D3s
However at 16 characters or more even the default options still
provide quite a bit of entropy and would be hard to exploit.
The biggest problem I have found using random passwords is that some
sites truncate the password to a shorter number of characters. Some
of those are fairly high profile sites! http://www.schwab.com/ is a
good example that truncates passwords at eight characters. There is
no defensible rationale for doing that truncation. When I see that I
assume that means that they are storing the plaintext of the password
somewhere. Otherwise if they were properly hashing the password why
would they feel the need to truncate it?
Bob
Jerry Stuckle
Jun 14, 2014, 10:40:02 PM6/14/14
to
On 6/14/2014 2:06 PM, Patrick Chkoreff wrote:
> Don Armstrong wrote, On 06/14/2014 01:04 PM:
>
>> If you just want purely random passwords, though, you might try
>> makepasswd instead. pwgen is more biased towards generating
>> distinguishable, memorable passwords instead of truly random ones.
>
> Here's a way to generate a *truly* random password that is *also* memorable:
>
> http://diceware.com
>
> Instead of using your computer to generate allegedly random bits, you
> use five six-sided dice to generate truly random bits.
>
>
> -- Patrick
>
>
Not good at all. With 5 dice, you have 6^5 or 7,776 possible
> Don Armstrong wrote, On 06/14/2014 01:04 PM:
>
>> If you just want purely random passwords, though, you might try
>> makepasswd instead. pwgen is more biased towards generating
>> distinguishable, memorable passwords instead of truly random ones.
>
> Here's a way to generate a *truly* random password that is *also* memorable:
>
> http://diceware.com
>
> Instead of using your computer to generate allegedly random bits, you
> use five six-sided dice to generate truly random bits.
>
>
> -- Patrick
>
>
combinations. Just figuring 5 upper and lower case characters and
numbers, you have 62^5 or 916,132,832 (more if you add special
characters). Even a 3 alphanumeric (upper and lower) case character
password has 238,328 possible combinations.
I wouldn't even consider this a weak password. It's much worse than
that. The fact you can have combinations of words doesn't add that much
security, especially if someone thinks you're using the diceware list.
Jerry
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
davi...@ling.ohio-state.edu
Jun 15, 2014, 12:40:01 AM6/15/14
to
On Sat, 14 Jun 2014, Bob Proulx wrote:
> The biggest problem I have found using random passwords is that some
> sites truncate the password to a shorter number of characters. Some
> of those are fairly high profile sites! http://www.schwab.com/ is a
> good example that truncates passwords at eight characters. There is
> no defensible rationale for doing that truncation. When I see that I
> assume that means that they are storing the plaintext of the password
> somewhere. Otherwise if they were properly hashing the password why
> would they feel the need to truncate it?
well, this doesn't look all that old...
> The biggest problem I have found using random passwords is that some
> sites truncate the password to a shorter number of characters. Some
> of those are fairly high profile sites! http://www.schwab.com/ is a
> good example that truncates passwords at eight characters. There is
> no defensible rationale for doing that truncation. When I see that I
> assume that means that they are storing the plaintext of the password
> somewhere. Otherwise if they were properly hashing the password why
> would they feel the need to truncate it?
http://docs.oracle.com/cd/E18752_01/html/816-4558/toc.html
>> The System Administration Guide: Naming and Directory Services (NIS+)
>>
>> Copyright © 1994, 2010, Oracle and/or its affiliates. All rights reserved.
and, drilling down a little...
http://docs.oracle.com/cd/E18752_01/html/816-4558/a08paswd-15680.html
>> A password must meet the following requirements:
>> * Length. By default, a password must have at least six characters. Only the first eight
>> characters are significant. (In other words, you can have a password that is longer than
>> eight characters, but the system only checks the first eight.) Because the minimum
>> length of a password can be changed by a system administrator, it may be different on
>> your system.
pretty nice, eh?
there is an NIS package in debian. couldn't find any indication of
its maximum (significant) password length, myself. does it check more
than eight characters?
-wes
Iain M Conochie
Jun 15, 2014, 6:10:02 AM6/15/14
to
On 14/06/14 13:57, Brian wrote:
> On Sat 14 Jun 2014 at 11:50:57 +0100, Iain M Conochie wrote:
>
>> Can you categorically state what _are_ the preseed options for the
>> openssh-server package? I can find 4:
> The ones you listed below are for a fresh install of Wheezy. Jessie is
> different. This output can be obtained from
>
> debconf-show openssh-server
Excellent. Thanks Brian. That is exactly what I wanted
> On Sat 14 Jun 2014 at 11:50:57 +0100, Iain M Conochie wrote:
>
>> Can you categorically state what _are_ the preseed options for the
>> openssh-server package? I can find 4:
> The ones you listed below are for a fresh install of Wheezy. Jessie is
> different. This output can be obtained from
>
> debconf-show openssh-server
Cheers
Iain
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Lisi Reisz
Jun 15, 2014, 6:40:01 AM6/15/14
to
On Saturday 14 June 2014 19:06:40 Patrick Chkoreff wrote:
> Don Armstrong wrote, On 06/14/2014 01:04 PM:
> > If you just want purely random passwords, though, you might try
> > makepasswd instead. pwgen is more biased towards generating
> > distinguishable, memorable passwords instead of truly random ones.
>
> Here's a way to generate a *truly* random password that is *also*
> memorable:
>
> http://diceware.com
>
> Instead of using your computer to generate allegedly random bits, you
> use five six-sided dice to generate truly random bits.
But:
> Don Armstrong wrote, On 06/14/2014 01:04 PM:
> > If you just want purely random passwords, though, you might try
> > makepasswd instead. pwgen is more biased towards generating
> > distinguishable, memorable passwords instead of truly random ones.
>
> Here's a way to generate a *truly* random password that is *also*
> memorable:
>
> http://diceware.com
>
> Instead of using your computer to generate allegedly random bits, you
> use five six-sided dice to generate truly random bits.
a) that will generate numeric only, and in the decimal system, which is what
is used on normal six-sided dice, that is permutations of only 10 characters
and
b) you are assuming that the dice are not in any way loaded, which is
unlikely.
Lisi
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Lisi Reisz
Jun 15, 2014, 6:40:01 AM6/15/14
to
Tom H
Jun 15, 2014, 7:10:01 AM6/15/14
to
Debian (or nisplus if it's available) doesn't have that restriction.
The paswword length in that documentation is restricted by the default
crypt policy of Solaris =<10 because it uses crypt_unix (the
traditional unix crypt algorithm), which doesn't support a password
length >8. IIRC, the ability to change the default crypt policy was
introduced with Solaris 9 in 2002.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Celejar
Jun 17, 2014, 7:50:01 PM6/17/14
to
On Sat, 14 Jun 2014 22:32:16 -0400
Jerry Stuckle <jstu...@attglobal.net> wrote:
> On 6/14/2014 2:06 PM, Patrick Chkoreff wrote:
...
Jerry Stuckle <jstu...@attglobal.net> wrote:
> On 6/14/2014 2:06 PM, Patrick Chkoreff wrote:
> > Here's a way to generate a *truly* random password that is *also* memorable:
> >
> > http://diceware.com
> >
> > Instead of using your computer to generate allegedly random bits, you
> > use five six-sided dice to generate truly random bits.
> >
> >
> > -- Patrick
> >
> >
>
> Not good at all. With 5 dice, you have 6^5 or 7,776 possible
> combinations. Just figuring 5 upper and lower case characters and
> numbers, you have 62^5 or 916,132,832 (more if you add special
> characters). Even a 3 alphanumeric (upper and lower) case character
> password has 238,328 possible combinations.
>
> I wouldn't even consider this a weak password. It's much worse than
> that. The fact you can have combinations of words doesn't add that much
> security, especially if someone thinks you're using the diceware list.
to use five dice *per word*, and recommend either five or six words as
a minimum:
http://world.std.com/~reinhold/diceware.html
http://world.std.com/~reinhold/dicewarefaq.html#howlong
Celejar
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Jerry Stuckle
Jun 17, 2014, 10:10:02 PM6/17/14
to
On 6/17/2014 7:41 PM, Celejar wrote:
> On Sat, 14 Jun 2014 22:32:16 -0400
> Jerry Stuckle <jstu...@attglobal.net> wrote:
>
>> On 6/14/2014 2:06 PM, Patrick Chkoreff wrote:
>
> ...
>
>>> Here's a way to generate a *truly* random password that is *also* memorable:
>>>
>>> http://diceware.com
>>>
>>> Instead of using your computer to generate allegedly random bits, you
>>> use five six-sided dice to generate truly random bits.
>>>
>>>
>>> -- Patrick
>>>
>>>
>>
>> Not good at all. With 5 dice, you have 6^5 or 7,776 possible
>> combinations. Just figuring 5 upper and lower case characters and
>> numbers, you have 62^5 or 916,132,832 (more if you add special
>> characters). Even a 3 alphanumeric (upper and lower) case character
>> password has 238,328 possible combinations.
>>
>> I wouldn't even consider this a weak password. It's much worse than
>> that. The fact you can have combinations of words doesn't add that much
>> security, especially if someone thinks you're using the diceware list.
>
> I think there's a miscommunication here; the diceware instructions are
> to use five dice *per word*, and recommend either five or six words as
> a minimum:
>
> http://world.std.com/~reinhold/diceware.html
> http://world.std.com/~reinhold/dicewarefaq.html#howlong
>
> Celejar
>
>
Yes, I understand. But a roll of five dice is less secure than a three
> On Sat, 14 Jun 2014 22:32:16 -0400
> Jerry Stuckle <jstu...@attglobal.net> wrote:
>
>> On 6/14/2014 2:06 PM, Patrick Chkoreff wrote:
>
> ...
>
>>> Here's a way to generate a *truly* random password that is *also* memorable:
>>>
>>> http://diceware.com
>>>
>>> Instead of using your computer to generate allegedly random bits, you
>>> use five six-sided dice to generate truly random bits.
>>>
>>>
>>> -- Patrick
>>>
>>>
>>
>> Not good at all. With 5 dice, you have 6^5 or 7,776 possible
>> combinations. Just figuring 5 upper and lower case characters and
>> numbers, you have 62^5 or 916,132,832 (more if you add special
>> characters). Even a 3 alphanumeric (upper and lower) case character
>> password has 238,328 possible combinations.
>>
>> I wouldn't even consider this a weak password. It's much worse than
>> that. The fact you can have combinations of words doesn't add that much
>> security, especially if someone thinks you're using the diceware list.
>
> I think there's a miscommunication here; the diceware instructions are
> to use five dice *per word*, and recommend either five or six words as
> a minimum:
>
> http://world.std.com/~reinhold/diceware.html
> http://world.std.com/~reinhold/dicewarefaq.html#howlong
>
> Celejar
>
>
character alphanumeric (upper and lower case) password (7,776 vs.
238,328 combinations). A 6 word password would have approximately the
same security as a 13 character alphanumeric password.
But then you have to type 30-40 characters or so to enter the diceware
password; very few (if any) sites will accept a password that long. The
longest I know of is around 20 characters (my bank).
That severely limits the number of combinations you can get with dice.
Jerry
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Celejar
Jun 18, 2014, 10:00:02 AM6/18/14
to
On Tue, 17 Jun 2014 22:00:49 -0400
Understood. I think the point of diceware, though, is that it generates
passphrases with at least a fair bit of entropy and that are still
relatively easy to remember, as per the celebrated xkcd:
http://xkcd.com/936/
Of course, your *genuinely* random 13 character password will be just
as good, but likely harder to remember.
> But then you have to type 30-40 characters or so to enter the diceware
> password; very few (if any) sites will accept a password that long. The
> longest I know of is around 20 characters (my bank).
>
> That severely limits the number of combinations you can get with dice.
True. I think they're mainly useful for local system passphrases, such
as GPG and LUKS keys.
> Jerry
Celejar
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/20140618095803.51ca...@gmail.com
passphrases with at least a fair bit of entropy and that are still
relatively easy to remember, as per the celebrated xkcd:
http://xkcd.com/936/
Of course, your *genuinely* random 13 character password will be just
as good, but likely harder to remember.
> But then you have to type 30-40 characters or so to enter the diceware
> password; very few (if any) sites will accept a password that long. The
> longest I know of is around 20 characters (my bank).
>
> That severely limits the number of combinations you can get with dice.
as GPG and LUKS keys.
> Jerry
Celejar
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
0 new messages