Re: need a tutorial on setuid

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sat, May 06, 2017 at 10:40:59PM -0500, Michael Milliman wrote:
> I can't see how dd could have been the culprit [...]

Definitely. The file system's inner structure isn't known to dd. One
possibility is that the subsequent mount is suppressing the suid bit
(a security feature: imagine I give you an USB stick with a suid
binary which you invoke without noticing...).

Check mount's suid option.

Cheers
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlkO3V8ACgkQBcgs9XrR2kaClgCeNhEyP5uCVlTecd/62KUjujld
AAMAn00R6ZKHq0BH3KWjemcDdzgi/L5u
=WoU5
-END PGP SIGNATURE-

Re: need a tutorial on setuid

[Michael Milliman]

I can't see how dd could have been the culprit. dd is a block for block
copy and does not modify the data as it copies. I don't doubt that the
setup bits were changed, but I would suggest that you look for what really
changed those bits to prevent a future occurrence.

73's,
de WB5VQX -- The Very Quick X-ray

On May 6, 2017 9:52 PM, "Gene Heskett"  wrote:

> Greetings all;
>
> The man page for chmod has obviously been edited to remove all useful
> information.
>
> My reason asking is it appears that dd, when making a clone of an sd
> card, seems to have removed all setuid info from the executable files.
> So I'm apparently going to have to restore things as the lack is
> discovered.
>
> Thanks
>
> Cheers, Gene Heskett
> --
> "There are four boxes to be used in defense of liberty:
>  soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author)
> Genes Web page 
>
>

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

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, Sep 23, 2016 at 04:41:00PM +, Stephan Beck wrote:
> Thank you very much, Tomás.

glad to help.

[...]

> 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?

That's how it's supposed to work (strictly speaking it doesn't present
the private part of the key, but just a *proof* that it is in control
of said private part, which the host account (test) can check).

The ssh-agent is just in charge of keeping unlocked private keys around
so that you only have to unlock them with your passphrase once per
session.

> 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.

Exactly: the authorized_keys is a per-account thing, meaning "whoever
has the private key corresponding to *this* public key is allowed
to log in as me". Note that you even can restrict what commands are
allowed for each private key -- a "backup" user would only be allowed
to invoke a specific backup script at login, for example.

> > (the chown just in case authorized_keys didn't exist before).

[...]

> >   - 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.

And it would only make sense if you go "industrial", as in "every user
on this box shall allow the user "backup" to invoke the per-user
backup script" or some such. I haven't needed that. Just a copy (or
an ssh-copy-id, if at he beginning the password access is available).

Regards
- -- t
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlfmh/cACgkQBcgs9XrR2ka8lwCdEDbXPQ4Rhr24DmzstfbuzThD
LoIAn1BE33kb23NvEPuidLvc7NxAUnN5
=qpNT
-END PGP SIGNATURE-

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

[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 +, 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

[Stephan Beck]

Thank you very much, Tomás.

to...@tuxteam.de:
> On Fri, Sep 23, 2016 at 12:31:00PM +, 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

[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

[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 +, 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

[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

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

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, Sep 23, 2016 at 12:31:00PM +, Stephan Beck wrote:
> Hi
> 
> to...@tuxteam.de:
> > On Thu, Sep 22, 2016 at 03:35:00PM +, 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.

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?

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).

> 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'

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

(the chown just in case authorized_keys didn't exist before).

> 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.

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)

  - creating the user's home directory from a prepared skeleton
already containing an "authorized_keys" as you need it

But all those methods need you being root at the machine where
*test* is created. You have to be root to create *test* in the
first place, though! So the proposed method above seems the
least intrusive to me.

Regards
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlflK5QACgkQBcgs9XrR2kb0AACeO1pPTe9vm31zAzvWVhNdH/Wb
EqUAn1Ftz5STEPa2JHhXScrq7nrYbpPa
=cIRd
-END PGP SIGNATURE-

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

[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.


Stephan

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

[Greg Wooledge]

On Fri, Sep 23, 2016 at 12:31: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.

Typically, you want to create the keypair as the user on the machine which
will be the client.  This way the private key never has to be touched,
moved, looked at, etc.

So, you want to ssh
FROM user "stephan" on this machine
TO   user "test"on this (same) machine

The private key needs to reside in ~stephan/.ssh/ where the client will
see it.

The public key needs to be concatenated into ~test/.ssh/authorized_keys
where the server will see it.

> How do I get this public key onto localhost?

Trick question.  You are already on the correct machine.  You just need
to have everything in the correct places (files/directories) with the
correct ownerships.

> 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.

As user stephan:

stephan@hostname:~$ ssh-keygen

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

(Of course, if you prefer you could just obtain a root shell and then run
all of the commands without sudo.)

As user stephan, to test that it works:

stephan@hostname:~$ ssh test@localhost id

If your username isn't actually "stephan", substitute accordingly.

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

[Stephan Beck]

Hi

to...@tuxteam.de:
> On Thu, Sep 22, 2016 at 03:35:00PM +, 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

[Dominique Dumont]

On Thursday, 22 September 2016 22:27:14 CEST Gene Heskett wrote:
> On Thursday, 22 September 2016 12:30:10 CEST Gene Heskett wrote:
> > > If you're not sure of the syntax of ssh config file, you can use
> > > 
> > > 
> > > 
> > > 
> > > cme=command not found.
> > 
> > You need to install cme package:
> > $ sudo apt install cme
> 
> Apparently not available for wheezy.

On Jessie and Wheezy, cme command is delivered by libconfig-model-perl.
I don't remember how the dependencies were organised, so please  install also
libconfig-model-openssh-perl and libconfig-model-tkui-perl

cme package is available on testing and sid.

All the best

-- 
 https://github.com/dod38fr/   -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/  -o-   irc: dod at irc.debian.org

Re: Need a tutorial

[davidson]

On Thu, 22 Sep 2016, Gene Heskett wrote:


On Thursday 22 September 2016 08:06:34 Lars Noodén wrote:

OpenSSH 6.5 or later will support it.  Wheezy had 6.0 (but 6.6 is in
the backports), and Jessia has 6.7, and Stretch is getting 7.3.  The
release notes for 6.5 just mention that it is "better" for security
and performance.


And I am on wheezy yet, because it Just Works,


Same here. Wheezy.


so I have 6.6p1-4bpo70+1, presumably with a bunch of patches.  So
there is no way to easily determine what patches have been
applied.


Not sure I follow you here.


I don't see a ChangeLog in any of those packages.


On my system:

  $ for pkg in openssh-{client,server} ; do apt-get changelog ${pkg} ; done
  Err Changelog for openssh-client 
(http://packages.debian.org/changelogs/pool/updates/main/o/openssh/openssh_6.0p1-4+deb7u6/changelog)
404  Not Found [IP: 213.165.95.4 80]
  Err Changelog for openssh-client 
(http://security.debian.org/pool/updates/main/o/openssh/openssh_6.0p1-4+deb7u6.changelog)
404  Not Found [IP: 128.101.240.215 80]
  E: changelog download failed
  Err Changelog for openssh-server 
(http://packages.debian.org/changelogs/pool/updates/main/o/openssh/openssh_6.0p1-4+deb7u6/changelog)
404  Not Found [IP: 5.153.231.3 80]
  Err Changelog for openssh-server 
(http://security.debian.org/pool/updates/main/o/openssh/openssh_6.0p1-4+deb7u6.changelog)
404  Not Found [IP: 128.101.240.215 80]
  E: changelog download failed

As shown, I get only errors, not changelogs. But, as you can already
tell from the errors above, I don't have the backported release 6.6 of
either package installed:

 $ dpkg-query -W openssh-{client,server}
 openssh-client  1:6.0p1-4+deb7u6
 openssh-server  1:6.0p1-4+deb7u6

Instead I currently have installed release 6.0, from regular wheezy
repo, and the last applied update was a security update.

But, regardless, just because "apt-get changelog" can't get them
doesn't mean *I* can't get the changelogs for my version, and examine
patches. For example:

  $ apt-get --diff-only source openssh-client="$(dpkg-query -Wf '${Version}' 
openssh-client)"
  [output snipped]

  $ ls  # notice the absence of "-client,-server" in filename; hence, afaict, 
apt-get changelog fails
  openssh_6.0p1-4+deb7u6.debian.tar.gz

  $ gunzip openssh_6.0p1-4+deb7u6.debian.tar.gz && tar xf 
openssh_6.0p1-4+deb7u6.debian.tar

  $ head debian/changelog
  openssh (1:6.0p1-4+deb7u6) wheezy-security; urgency=high

* Non-maintainer upload by the Long Tem Security Team.
* Limit password length to avoid DOS attack (CVE-2016-6515). Closes:
  #833823.

   -- Ola Lundqvist   Tue, 09 Aug 2016 09:56:02 +

  openssh (1:6.0p1-4+deb7u5) wheezy-security; urgency=high

  $ ls debian/patches/*.patch | wc -l
  35

So that's my system.

Now, you say you have the backported releases, version 1:6.6p1-4~bpo70+1 
installed on yours.

But "apt-get changelog" *will* fetch changelogs for this version. Running this 
command

 $ for pkg in openssh-{client,server} ; do apt-get changelog 
${pkg}=1:6.6p1-4~bpo70+1 ; done

on my system shows them to me. I believe it should do so on yours,
too, if you have wheezy-backports repo enabled in your sources.list.

If running, on your system,

  $ for pkg in openssh-{client,server} ; do apt-get changelog ${pkg} ; done

without specifying a version does not also show you those same
changelogs, then something does not add up.

Cheers.

--
# Duplex (telecommunications) - Wikipedia, the free encyclopedia

  Systems that do not need the duplex capability may instead use
  simplex communication, in which one device transmits and the others
  can only "listen". Examples are broadcast radio and television,
  garage door openers, baby monitors, wireless microphones, and
  surveillance cameras. In these devices communication is only in one
  direction.

Re: Need a tutorial

[Gene Heskett]

On Thursday 22 September 2016 14:18:30 Dominique Dumont wrote:

> On Thursday, 22 September 2016 12:30:10 CEST Gene Heskett wrote:
> > If you're not sure of the syntax of ssh config file, you can use
> >
> > > 'cme edit ssh' to perform this task.
> >
> > cme=command not found.
>
> You need to install cme package:
> $ sudo apt install cme
>
Apparently not available for wheezy.

> This will install al required dependencies unless you've configured
> apt to avoid installation of recommended dependencies.
>
> HTH


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: Need a tutorial

[Thomas Schmitt]

Hi,

Dominique Dumont wrote:
> > > > If you're not sure of the syntax of ssh config file, you can use
> > > > 'cme edit ssh' to perform this task.

Gene Heskett wrote:
> > > cme=command not found.

Dominique Dumont wrote:
> > You need to install cme package:
> > $ sudo apt install cme

Greg Wooledge wrote:
> > I know nothing about this "cme" either.

You will love the first statement in its man page :)~

   cme - Check or edit configuration data with Config::Model

It invites us all to participate in improvement

   FEEDBACKS
   Feedback from users are highly desired.
   ...
   AUTHOR
   Dominique Dumont


Bob Bernstein wrote.
> Yes. Qu'est-que "cme?"

I guess perl docs can give info additional to the man page.
  http://search.cpan.org/dist/Config-Model/lib/Config/Model.pm
says

  "Config::Model - Create tools to validate, migrate and edit configuration
   files."
  "Config::Model enables a project developer to provide an interactive
   configuration editor (graphical, curses based or plain terminal) to
   users."

Obviously it knows several file formats and even the file names
which it shall operate on.
For me it checks my Debian packaging preparations by

  cme check dpkg

(Zero answer is good answer, then.)


Have a nice day :)

Thomas

Re: Need a tutorial

[Dominique Dumont]

On Thursday, 22 September 2016 14:29:53 CEST Greg Wooledge wrote:
> wooledg@wooledg:~$ apt-cache show cme
> N: Unable to locate package cme
> E: No packages found

Ah sorry, cme package is available on testing and sid.

On Jessie, cme command is delivered by libconfig-model-perl.
I don't remember how the dependencies were organised, so please  install also
libconfig-model-openssh-perl and libconfig-model-tkui-perl

All the best

-- 
 https://github.com/dod38fr/   -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/  -o-   irc: dod at irc.debian.org

Re: Need a tutorial

[Greg Wooledge]

On Thu, Sep 22, 2016 at 08:18:30PM +0200, Dominique Dumont wrote:
> On Thursday, 22 September 2016 12:30:10 CEST Gene Heskett wrote:
> > If you're not sure of the syntax of ssh config file, you can use
> > 
> > > 'cme edit ssh' to perform this task.
> > 
> > cme=command not found.
> 
> You need to install cme package:
> $ sudo apt install cme

wooledg@wooledg:~$ apt-cache show cme
N: Unable to locate package cme
E: No packages found

Re: Need a tutorial

[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

[Dominique Dumont]

On Thursday, 22 September 2016 12:30:10 CEST Gene Heskett wrote:
> If you're not sure of the syntax of ssh config file, you can use
> 
> > 'cme edit ssh' to perform this task.
> 
> cme=command not found.

You need to install cme package:
$ sudo apt install cme

This will install al required dependencies unless you've configured apt to 
avoid installation of recommended dependencies.

HTH

-- 
 https://github.com/dod38fr/   -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/  -o-   irc: dod at irc.debian.org

Re: Need a tutorial

[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

[Bob Bernstein]

On Thu, 22 Sep 2016, Greg Wooledge wrote:


cme=command not found.



I know nothing about this "cme" either.


Yes. Qu'est-que "cme?"

Some esoteric breed of editor?

--
IMPORTANT: This email is intended for the use of the individual
addressee(s) named above and may contain information that is
confidential, privileged or unsuitable for overly sensitive
persons with low self-esteem, no sense of humour or irrational
metaphysical beliefs.

Re: Need a tutorial

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, Sep 22, 2016 at 03:35:00PM +, 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 :-)

But I see you found a solution and other chimed in with sage advice.

Regards
- -- t
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlfkFd0ACgkQBcgs9XrR2kYIzwCcDK3OkCB1HILwCpFkgyrIla2V
OCEAn2MpMIpG4TfpTTcNEqL32QJiAQr9
=WDsS
-END PGP SIGNATURE-

Re: Need a tutorial

[Lars Noodén]

On 09/22/2016 07:30 PM, Gene Heskett wrote:
> On Thursday 22 September 2016 11:16:45 Dominique Dumont wrote:
...
>> Others have explained how to generate keys. Then you can simplify the
>> process by setting up your ~/.ssh/config file with something like:
>>
> Interesting, I don't have that file, its all in /etc/ssh.

ssh_config is probably the most under-appreciated part of the client.
Yet it's very useful.  Even a lot of 3rd party tools work with it.

The global file is /etc/ssh/ssh_config.  Most users have one located in
~/.ssh/config  For both, the full documentation is in the manual page
for "ssh_config".  If you add a lot of options then it saves a lot of
work to put them in ~/.ssh/config

If the file does not exist, you can make it with your choice of editor.
It follows the basic structure of Host + a pattern or name, followed by
options for that pattern or name.  For example, these blocks add a set
of options below for two remote hosts:

Host 5501
  Hostname 203.0.113.22
  IdentitiesOnly yes
  IdentityFile ~/.ssh/key_22_ed25519
  AddKeysToAgent yes
  ServerAliveCountMax 2
  ServerAliveInterval 30
  Port 2223

Host 33
  User xyzzy
  HostName 203.0.113.11
  ControlPath ~/.ssh/controlmasters/%r@%h:%p
  ControlMaster autoask
  ControlPersist yes

The first host with its set of options is available via "ssh 5501", just
as the second one is available via "ssh 33".  The latter would be the
equivalent of

  ssh -o ControlPath=~/.ssh/controlmasters/%r@%h:%p \
 -o ControlMaster=autoask \
 -o ControlPersist=yes \
 xyzzy@203.0.113.11

Or something like that.

I recommend grabbing a refreshment, finding a comfy chair, and working
through the manual page for ssh_config paragraph by paragraph at least
once if you connect to a lot of servers or use a lot of options when
connecting.

Regards,
Lars

Re: Need a tutorial

[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

[Greg Wooledge]

On Thu, Sep 22, 2016 at 12:30:10PM -0400, Gene Heskett wrote:
> On Thursday 22 September 2016 11:16:45 Dominique Dumont wrote:
> > Others have explained how to generate keys. Then you can simplify the
> > process by setting up your ~/.ssh/config file with something like:
> >
> Interesting, I don't have that file, its all in /etc/ssh.

Create it if it doesn't exist.  Create the ~/.ssh/ directory first, if
that doesn't exist either.

> > Host shop lathe GO704
> >  user gene
> >  # private key file
> >  IdentityFile ~/.ssh/my_key_for_sshfs
> >
> > If you want to use different keys for the several hosts, you will have
> > to duplicate the config snippet shown above.

More generally, ~/.ssh/config (which does not exist by default but which
can be created) is the user-level configuration for the ssh client
program.  The system-level defaults are in /etc/ssh/ssh_config.

Also, as long as you're messing with ~/.ssh/config you might want to
set up a keepalive in case you ever communicate through a NAT router.

ServerAliveInterval 300

will send a packet every 300 seconds, which (hopefully) prevents a NAT
router from timing out your idle sessions.

(Yeah, I know, it says "Server" but it's a client-side config option.
I didn't choose the name.)

> > If you're not sure of the syntax of ssh config file, you can use
> > 'cme edit ssh' to perform this task.
> 
> cme=command not found.

I know nothing about this "cme" either.

Re: Need a tutorial

[Gene Heskett]

On Thursday 22 September 2016 12:04:21 Lars Noodén wrote:

> On 09/22/2016 06:55 PM, Gene Heskett wrote:
> > Can ssh-keygen make the newer ones above? I see in a key acceptance
> > conversation that it apparently can do the ecdsa. So maybe I
> > shouldn't worry.
>
> The -t option sets the key type that ssh-keygen will make.  These days
> it you can choose from DSA, ECDSA, RSA, or Ed25519.  Any except DSA
> ought to be ok.  If you run into a dongle or helper application which
> has trouble with Ed25519, then you could file a bug report and ug make
> an RSA key (with enough bits) for that one instead.
>
> Regards,
> Lars
Thanks Lars

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: Need a tutorial

[Gene Heskett]

On Thursday 22 September 2016 11:16:45 Dominique Dumont wrote:

> On Wednesday, 21 September 2016 10:18:55 CEST Gene Heskett wrote:
> > su gene -c "sshfs gene@shop:/ /sshnet/shop"
> > su gene -c "sshfs gene@lathe:/ /sshnet/lathe"
> > su gene -c "sshfs gene@GO704:/ /sshnet/GO704"
>
> Others have explained how to generate keys. Then you can simplify the
> process by setting up your ~/.ssh/config file with something like:
>
Interesting, I don't have that file, its all in /etc/ssh.

> Host shop lathe GO704
>  user gene
>  # private key file
>  IdentityFile ~/.ssh/my_key_for_sshfs
>
> If you want to use different keys for the several hosts, you will have
> to duplicate the config snippet shown above.
>
> If you're not sure of the syntax of ssh config file, you can use
> 'cme edit ssh' to perform this task.

cme=command not found.
> HTH
>
> All the best


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: Need a tutorial

[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 ...)


Have a nice day :)

Thomas

Re: Need a tutorial

[Gene Heskett]

On Thursday 22 September 2016 09:42:18 Jude DaShiell wrote:

> Also, make a list of all crypto types ssh-keygen can do and check on
> the internet and eliminate the obsolete encryption types from the
> types you'll use to create that key pair before creating that key
> pair.
>
Good advice, thanks Jude.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: Need a tutorial

[Stephan Beck]

Thanks, Greg.

Greg Wooledge:
> On Thu, Sep 22, 2016 at 03:35:00PM +, 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

[Gene Heskett]

On Thursday 22 September 2016 08:06:34 Lars Noodén wrote:

> On 09/22/2016 02:09 PM, Gene Heskett wrote:
> > On Thursday 22 September 2016 03:44:28 Lars Noodén wrote:
>
> ...
>
> >> As far as the key choices go, DSA is considered deprecated, at
> >> least in the more recent versions:
> >>
> >>"Support for ssh-dss, ssh-dss-cert-* host and user keys
> >>will be run-time disabled by default"
> >> - http://www.openssh.com/txt/release-6.9
> >>
> >> So that leaves RSA if you have old versions of the OpenSSH server
> >> to deal with.  Probably 2048 bits or more is good for a while.
> >> Otherwise, consider Ed25519.
> >
> > This I am not familiar with. Is there an explanatory url?
>
> Well, it was officially turned off in 7.0, just like warned above:
>
> http://www.openssh.com/txt/release-7.0
>
> and there was a bit of discussion around the net like this one:
>
> http://meyering.net/nuke-your-DSA-keys/
>
> But as far as explanations go, that's like the others I've seen to
> phase out any remaining DSA use due to weaknesses.  The articles I've
> seen are either cryptographer level (and thus beyond me) or very
> generic, but the there are multiple problems with DSA at this point.
>
> Ed25519 claims these benefits:
>
> https://ed25519.cr.yp.to/
>
> OpenSSH 6.5 or later will support it.  Wheezy had 6.0 (but 6.6 is in
> the backports), and Jessia has 6.7, and Stretch is getting 7.3.  The
> release notes for 6.5 just mention that it is "better" for security
> and performance.

And I am on wheezy yet, because it Just Works, so I have 6.6p1-4bpo70+1, 
presumably with a bunch of patches.  So there is no way to easily 
determine what patches have been applied. I don't see a ChangeLog in any 
of those packages. 30 lashes with a wet noodle on whoever made the call 
to leave out the ChangeLog's.  Sigh...

> Regards,
> Lars


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: Need a tutorial

[Greg Wooledge]

On Thu, Sep 22, 2016 at 06:11:18PM +0200, Thomas Schmitt wrote:
> 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 
> [...]
>   $

Well, that's not a fair test.  The previous poster was running adduser,
so he already had superuser privileges, either through sudo or su or
direct root console/ssh login.  From whichever shell he was using to
run adduser, he should also be able to run sudo -u test bash.

Re: Need a tutorial

[Thomas Schmitt]

Hi,

Stephan Beck wrote:
> How can you access this new account to generate an ssh key pair there?

There seems to be a bug with adduser --disabled-password .
With empty password input i get:

  $ su test_user
  Password: 
  su: Authentication failure

Only this succeeds:

  $ su
  Password: 
  # su test_user
  $ whoami
  test_user

adduser gave the user this line in /etc/passwd:

  test_user:x:::Test User,,,:/home/test_user:/bin/bash

and in /etc/shadow

  test_user:*:17066:0:9:7:::


Above will not work with users who have /usr/sbin/nologin as shell

  "NOLOGIN(8)System Management Commands   NOLOGIN(8)

   NAME
  nologin - politely refuse a login
  "

which is used to nail up the user's lines in /etc/passwd like:

  backup:x:34:34:backup:/var/backups:/usr/sbin/nologin

resulting in

  # su backup
  This account is currently not available.

One has to work around by explicitely giving the shell to use

  # su backup -s /bin/bash
  $ whoami
  backup


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 [...]
  $


Have a nice day :)

Thomas

Re: Need a tutorial

[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

[Lars Noodén]

On 09/22/2016 06:55 PM, Gene Heskett wrote:
> Can ssh-keygen make the newer ones above? I see in a key acceptance 
> conversation that it apparently can do the ecdsa. So maybe I shouldn't 
> worry. 

The -t option sets the key type that ssh-keygen will make.  These days
it you can choose from DSA, ECDSA, RSA, or Ed25519.  Any except DSA
ought to be ok.  If you run into a dongle or helper application which
has trouble with Ed25519, then you could file a bug report and ug make
an RSA key (with enough bits) for that one instead.

Regards,
Lars

Re: Need a tutorial

[Gene Heskett]

On Thursday 22 September 2016 08:02:56 to...@tuxteam.de wrote:

> On Thu, Sep 22, 2016 at 07:09:53AM -0400, Gene Heskett wrote:
> > On Thursday 22 September 2016 03:44:28 Lars Noodén wrote:
> > > On 09/21/2016 11:39 PM, Gene Heskett wrote:
> > > > On Wednesday 21 September 2016 10:23:09 Greg Wooledge wrote:
> > >
> > > ...
> > >
> > > >> man ssh-keygen
> > > >> http://mywiki.wooledge.org/SshKeys
> > > >
> > > > I knew there was something about generating keys, but not the
> > > > sticky details.
> > >
> > > If you have multiple servers or multiple remote accounts, you will
> > > end up with at least one key pair per account+server.  So you will
> > > also need a way to keep track of them.  One way it to make use of
> > > the -C and -f options to add a comment inside the key and to name
> > > the key files to something mnemonic.
> >
> > Now that would be very handy.
> >
> > > As far as the key choices go, DSA is considered deprecated, at
> > > least in the more recent versions:
> > >
> > >   "Support for ssh-dss, ssh-dss-cert-* host and user keys
> > >   will be run-time disabled by default"
> > >- http://www.openssh.com/txt/release-6.9
> > >
> > > So that leaves RSA if you have old versions of the OpenSSH server
> > > to deal with.  Probably 2048 bits or more is good for a while.
> > > Otherwise, consider Ed25519.
> >
> > This I am not familiar with. Is there an explanatory url?
>
> In general:
>
>  
> https://debian-administration.org/article/530/SSH_with_authentication_
>key_instead_of_password
>
This one starts out good, but the comments section contains corrections 
that really should be incorporated into the main post itself.  I may run 
it thru some local editing just to get everything in order. In the 
meantime what I have working on the new machine is working but with 
passwords.

> On key choice:
>
>  
> http://security.stackexchange.com/questions/23383/ssh-key-type-rsa-dsa
>-ecdsa-are-there-easy-answers-for-which-to-choose-when

Can ssh-keygen make the newer ones above? I see in a key acceptance 
conversation that it apparently can do the ecdsa. So maybe I shouldn't 
worry. 

> regards
> -- t

Thanks, I think this answers the question nicely.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: Need a tutorial

[Greg Wooledge]

On Thu, Sep 22, 2016 at 03:35:00PM +, 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.

Re: Need a tutorial

[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: Need a tutorial

[Dominique Dumont]

On Wednesday, 21 September 2016 10:18:55 CEST Gene Heskett wrote:
> su gene -c "sshfs gene@shop:/ /sshnet/shop"
> su gene -c "sshfs gene@lathe:/ /sshnet/lathe"
> su gene -c "sshfs gene@GO704:/ /sshnet/GO704"

Others have explained how to generate keys. Then you can simplify the process 
by setting up your ~/.ssh/config file with something like:

Host shop lathe GO704
 user gene
 # private key file
 IdentityFile ~/.ssh/my_key_for_sshfs

If you want to use different keys for the several hosts, you will have to 
duplicate the config snippet shown above.

If you're not sure of the syntax of ssh config file, you can use 
'cme edit ssh' to perform this task.

HTH

All the best

-- 
 https://github.com/dod38fr/   -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/  -o-   irc: dod at irc.debian.org

Re: Need a tutorial

[Jude DaShiell]

Also, make a list of all crypto types ssh-keygen can do and check on the 
internet and eliminate the obsolete encryption types from the types 
you'll use to create that key pair before creating that key pair.


On Wed, 21 Sep 2016, Greg Wooledge wrote:


Date: Wed, 21 Sep 2016 10:23:09
From: Greg Wooledge 
To: debian-user@lists.debian.org
Subject: Re: Need a tutorial
Resent-Date: Wed, 21 Sep 2016 14:23:27 + (UTC)
Resent-From: debian-user@lists.debian.org

On Wed, Sep 21, 2016 at 10:18:55AM -0400, Gene Heskett wrote:

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:

su gene -c "sshfs gene@shop:/ /sshnet/shop"
su gene -c "sshfs gene@lathe:/ /sshnet/lathe"
su gene -c "sshfs gene@GO704:/ /sshnet/GO704"


You need to set up key authentication between your local account (as
client) and the remote server.  Usually this is done by having an ssh
keypair (generating one if you don't already have one), then sending
the public key (NOT the private key) to the remote machine, and appending
it to the ~/.ssh/authorized_keys file of the target account.

man ssh-keygen
http://mywiki.wooledge.org/SshKeys




--

Re: Need a tutorial

[Lars Noodén]

On 09/22/2016 02:09 PM, Gene Heskett wrote:
> On Thursday 22 September 2016 03:44:28 Lars Noodén wrote:
...
>> As far as the key choices go, DSA is considered deprecated, at least
>> in the more recent versions:
>>
>>  "Support for ssh-dss, ssh-dss-cert-* host and user keys
>>  will be run-time disabled by default"
>>   - http://www.openssh.com/txt/release-6.9
>>
>> So that leaves RSA if you have old versions of the OpenSSH server to
>> deal with.  Probably 2048 bits or more is good for a while. 
>> Otherwise, consider Ed25519.
>>
> This I am not familiar with. Is there an explanatory url?

Well, it was officially turned off in 7.0, just like warned above:

http://www.openssh.com/txt/release-7.0

and there was a bit of discussion around the net like this one:

http://meyering.net/nuke-your-DSA-keys/

But as far as explanations go, that's like the others I've seen to phase
out any remaining DSA use due to weaknesses.  The articles I've seen are
either cryptographer level (and thus beyond me) or very generic, but the
there are multiple problems with DSA at this point.

Ed25519 claims these benefits:

https://ed25519.cr.yp.to/

OpenSSH 6.5 or later will support it.  Wheezy had 6.0 (but 6.6 is in the
backports), and Jessia has 6.7, and Stretch is getting 7.3.  The release
notes for 6.5 just mention that it is "better" for security and
performance.

Regards,
Lars

Re: Need a tutorial

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, Sep 22, 2016 at 07:09:53AM -0400, Gene Heskett wrote:
> On Thursday 22 September 2016 03:44:28 Lars Noodén wrote:
> 
> > On 09/21/2016 11:39 PM, Gene Heskett wrote:
> > > On Wednesday 21 September 2016 10:23:09 Greg Wooledge wrote:
> >
> > ...
> >
> > >> man ssh-keygen
> > >> http://mywiki.wooledge.org/SshKeys
> > >
> > > I knew there was something about generating keys, but not the sticky
> > > details.
> >
> > If you have multiple servers or multiple remote accounts, you will end
> > up with at least one key pair per account+server.  So you will also
> > need a way to keep track of them.  One way it to make use of the -C
> > and -f options to add a comment inside the key and to name the key
> > files to something mnemonic.
> >
> Now that would be very handy.
> > As far as the key choices go, DSA is considered deprecated, at least
> > in the more recent versions:
> >
> > "Support for ssh-dss, ssh-dss-cert-* host and user keys
> > will be run-time disabled by default"
> >  - http://www.openssh.com/txt/release-6.9
> >
> > So that leaves RSA if you have old versions of the OpenSSH server to
> > deal with.  Probably 2048 bits or more is good for a while. 
> > Otherwise, consider Ed25519.
> >
> This I am not familiar with. Is there an explanatory url?

In general:

  
https://debian-administration.org/article/530/SSH_with_authentication_key_instead_of_password

On key choice:

  
http://security.stackexchange.com/questions/23383/ssh-key-type-rsa-dsa-ecdsa-are-there-easy-answers-for-which-to-choose-when

regards
- -- t
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlfjyHAACgkQBcgs9XrR2kY4zACeJoUy04HpVBz14F/jcTeamX75
32oAnjIETAvpmWzE/OSkQ7BOcjpdasY4
=dFdK
-END PGP SIGNATURE-

Re: Need a tutorial

[Gene Heskett]

On Thursday 22 September 2016 03:44:28 Lars Noodén wrote:

> On 09/21/2016 11:39 PM, Gene Heskett wrote:
> > On Wednesday 21 September 2016 10:23:09 Greg Wooledge wrote:
>
> ...
>
> >> man ssh-keygen
> >> http://mywiki.wooledge.org/SshKeys
> >
> > I knew there was something about generating keys, but not the sticky
> > details.
>
> If you have multiple servers or multiple remote accounts, you will end
> up with at least one key pair per account+server.  So you will also
> need a way to keep track of them.  One way it to make use of the -C
> and -f options to add a comment inside the key and to name the key
> files to something mnemonic.
>
Now that would be very handy.
> As far as the key choices go, DSA is considered deprecated, at least
> in the more recent versions:
>
>   "Support for ssh-dss, ssh-dss-cert-* host and user keys
>   will be run-time disabled by default"
>- http://www.openssh.com/txt/release-6.9
>
> So that leaves RSA if you have old versions of the OpenSSH server to
> deal with.  Probably 2048 bits or more is good for a while. 
> Otherwise, consider Ed25519.
>
This I am not familiar with. Is there an explanatory url?

> Regards,
> /Lars

Thanks Lars.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: Need a tutorial

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, Sep 22, 2016 at 10:44:28AM +0300, Lars Noodén wrote:
> On 09/21/2016 11:39 PM, Gene Heskett wrote:
> > On Wednesday 21 September 2016 10:23:09 Greg Wooledge wrote:
> ...
> >> man ssh-keygen
> >> http://mywiki.wooledge.org/SshKeys
> > 
> > I knew there was something about generating keys, but not the sticky 
> > details.
> 
> If you have multiple servers or multiple remote accounts, you will end
> up with at least one key pair per account+server.  So you will also need
> a way to keep track of them.  One way it to make use of the -C and -f
> options to add a comment inside the key and to name the key files to
> something mnemonic.

I actually use my default key for most servers. Only especially sensitive
(or especially insecure) servers get a dedicated key.

Of course I'm betting on the impossibility of recovering the secret key
from the public key, which is distributed around and available to anyone
capable of compromising one server.

Then, state-level attackers have much easier avenues than that. As Bruce
Schneier put it once, "NSA is better at breaking knuckles than at breaking
codes" :-/

But yes, it makes sense to think about the security/convenience tradeoffs.

regards
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlfjmPwACgkQBcgs9XrR2kbs4wCdHtG+7JkudYcnbSP+bViXDRrH
QSwAn3JbimtAVvQsLa1oXQi0zmK2FXAk
=XXY8
-END PGP SIGNATURE-

Re: Need a tutorial

[Lars Noodén]

On 09/21/2016 11:39 PM, Gene Heskett wrote:
> On Wednesday 21 September 2016 10:23:09 Greg Wooledge wrote:
...
>> man ssh-keygen
>> http://mywiki.wooledge.org/SshKeys
> 
> I knew there was something about generating keys, but not the sticky 
> details.

If you have multiple servers or multiple remote accounts, you will end
up with at least one key pair per account+server.  So you will also need
a way to keep track of them.  One way it to make use of the -C and -f
options to add a comment inside the key and to name the key files to
something mnemonic.

As far as the key choices go, DSA is considered deprecated, at least in
the more recent versions:

"Support for ssh-dss, ssh-dss-cert-* host and user keys
will be run-time disabled by default"
 - http://www.openssh.com/txt/release-6.9

So that leaves RSA if you have old versions of the OpenSSH server to
deal with.  Probably 2048 bits or more is good for a while.  Otherwise,
consider Ed25519.

Regards,
/Lars

Re: Need a tutorial

[Gene Heskett]

On Wednesday 21 September 2016 12:24:39 to...@tuxteam.de wrote:

> 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.
>
> regards
> -- t

Thanks Tomas, I'll see what I've missed.  Right now its working but its 
all passwd protected. Well enough I think I can get the public key 
moved.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: Need a tutorial

[Gene Heskett]

On Wednesday 21 September 2016 10:23:09 Greg Wooledge wrote:

> On Wed, Sep 21, 2016 at 10:18:55AM -0400, Gene Heskett wrote:
> > 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:
> >
> > su gene -c "sshfs gene@shop:/ /sshnet/shop"
> > su gene -c "sshfs gene@lathe:/ /sshnet/lathe"
> > su gene -c "sshfs gene@GO704:/ /sshnet/GO704"
>
> You need to set up key authentication between your local account (as
> client) and the remote server.  Usually this is done by having an ssh
> keypair (generating one if you don't already have one), then sending
> the public key (NOT the private key) to the remote machine, and
> appending it to the ~/.ssh/authorized_keys file of the target account.
>
> man ssh-keygen
> http://mywiki.wooledge.org/SshKeys

I knew there was something about generating keys, but not the sticky 
details.

Thanks.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: Need a tutorial

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

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.

regards
- -- t
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlfitEcACgkQBcgs9XrR2kbHtQCcDxCW1tvvn/iO2diu3Ke7efuC
C5gAn0iq813ipmLaxhYbiBvoahFEYQ0v
=0El5
-END PGP SIGNATURE-

Re: Need a tutorial

[Greg Wooledge]

On Wed, Sep 21, 2016 at 10:18:55AM -0400, Gene Heskett wrote:
> 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:
> 
> su gene -c "sshfs gene@shop:/ /sshnet/shop"
> su gene -c "sshfs gene@lathe:/ /sshnet/lathe"
> su gene -c "sshfs gene@GO704:/ /sshnet/GO704"

You need to set up key authentication between your local account (as
client) and the remote server.  Usually this is done by having an ssh
keypair (generating one if you don't already have one), then sending
the public key (NOT the private key) to the remote machine, and appending
it to the ~/.ssh/authorized_keys file of the target account.

man ssh-keygen
http://mywiki.wooledge.org/SshKeys