Subject: Need a tutorial

From: Gene Heskett <[email-masked]>
Date: Wed, 21 Sep 2016 10:18:55 -0400

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:

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

I am in the process of bringing up a 4th machine, but those messages seem 
to have disappeared from my email corpus. The folder they were in has a 
6 month expiry set. I should have marked them as important, but 
apparently I failed to do that, distracted by doing the procedure, which 
worked a treat.

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 <http://geneslinuxbox.net:6309/gene>

---

From: Dominique Dumont <[email-masked]>
Date: Thu, 22 Sep 2016 17:16:45 +0200

> 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

---

From: Gene Heskett <[email-masked]>
Date: Thu, 22 Sep 2016 12:30:10 -0400

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.

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

cme=command not found.

Cheers, Gene Heskett

---

From: Dominique Dumont <[email-masked]>
Date: Thu, 22 Sep 2016 20:18:30 +0200

> > 'cme edit ssh' to perform this task.

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

---

From: Gene Heskett <[email-masked]>
Date: Thu, 22 Sep 2016 22:27:14 -0400

> You need to install cme package:
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

---

From: Dominique Dumont <[email-masked]>
Date: Fri, 23 Sep 2016 09:13:44 +0200

> 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

---

From: Greg Wooledge <[email-masked]>
Date: Thu, 22 Sep 2016 14:29:53 -0400

> You need to install cme package:

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

---

From: Dominique Dumont <[email-masked]>
Date: Thu, 22 Sep 2016 20:39:57 +0200

> N: Unable to locate package cme

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

---

From: Lars Noodén <[email-masked]>
Date: Thu, 22 Sep 2016 20:03:46 +0300

> On Thursday 22 September 2016 11:16:45 Dominique Dumont wrote:
...
> 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 \
	 [email-masked]

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

---

From: Greg Wooledge <[email-masked]>
Date: Thu, 22 Sep 2016 12:54:19 -0400

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

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

> > 'cme edit ssh' to perform this task.

I know nothing about this "cme" either.

---

From: Bob Bernstein <[email-masked]>
Date: Thu, 22 Sep 2016 14:00:42 -0400 (EDT)

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

---

From: "Thomas Schmitt" <[email-masked]>
Date: Thu, 22 Sep 2016 20:53:39 +0200

Hi,

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

---

From: Stephan Beck <[email-masked]>
Date: Thu, 22 Sep 2016 15:35:00 +0000

[email-masked]:
> On Wed, Sep 21, 2016 at 10:18:55AM -0400, Gene Heskett wrote:
> 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.

---

From: Stephan Beck <[email-masked]>
Date: Fri, 23 Sep 2016 12:31:00 +0000

Hi

[email-masked]:
> On Thu, Sep 22, 2016 at 03:35:00PM +0000, Stephan Beck wrote:
> 
> 
>> [email-masked]:
> 
> [mumble]
> 
> 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

---

From: Stephan Beck <[email-masked]>
Date: Fri, 23 Sep 2016 16:41:00 +0000

Thank you very much, Tomás.

[email-masked]:
> On Fri, Sep 23, 2016 at 12:31:00PM +0000, Stephan Beck wrote:
>> Hi
>> [email-masked]:
[...]
> 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_rsa                authorized_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)

Uuuuuh! 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

---

From: Stephan Beck <[email-masked]>
Date: Fri, 23 Sep 2016 13:07:00 +0000

Hi

> 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

---

From: Stephan Beck <[email-masked]>
Date: Fri, 23 Sep 2016 13:51:00 +0000

Hi,

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

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 [email-masked]
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

---

From: Greg Wooledge <[email-masked]>
Date: Fri, 23 Sep 2016 08:51:02 -0400

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

> directory where it has been generated, it needs to be sent (or get

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.

---

From: Stephan Beck <[email-masked]>
Date: Fri, 23 Sep 2016 20:13:00 +0000

Hi Greg and Tomás (one mail for all to limit the load of this thread on
the list) :-)

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

>   chown test:test ~/test/.ssh/authorized_keys

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

---

From: Stephan Beck <[email-masked]>
Date: Fri, 23 Sep 2016 14:13:00 +0000

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

> 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

---

From: Stephan Beck <[email-masked]>
Date: Fri, 23 Sep 2016 14:19:00 +0000

> Thanks, Greg. I trimmed your message just to let you know that it does

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

---

From: "Thomas Schmitt" <[email-masked]>
Date: Thu, 22 Sep 2016 18:11:18 +0200

Hi,

> 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:<number>:<number>:Test User,,,:/home/test_user:/bin/bash

and in /etc/shadow

  test_user:*:17066:0:99999: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

---

From: Stephan Beck <[email-masked]>
Date: Thu, 22 Sep 2016 16:56:00 +0000

Hi,

>> How can you access this new account to generate an ssh key pair there?
[sorry for trimming]

>   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

---

From: Greg Wooledge <[email-masked]>
Date: Thu, 22 Sep 2016 12:14:16 -0400

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

---

From: "Thomas Schmitt" <[email-masked]>
Date: Thu, 22 Sep 2016 18:24:31 +0200

Hi,

Greg Wooledge wrote:
> From whichever shell he was using to

Ah yes. This works. (One just has to accomodate to the idea of the
superuser running sudo ...)

Have a nice day :)

Thomas

---

From: Stephan Beck <[email-masked]>
Date: Thu, 22 Sep 2016 18:08:00 +0000

Hi,

> superuser running sudo ...)

Yes, Greg and Thomas, I've just tried

sudo -u test bash

and it definitely works here as well.

Thanks

Stephan

---

From: Stephan Beck <[email-masked]>
Date: Thu, 22 Sep 2016 17:58:00 +0000

Hi,

sudo -u test bash

and it definitely works.

Thanks

Stephan

---

From: Stephan Beck <[email-masked]>
Date: Thu, 22 Sep 2016 16:03:00 +0000

I resolved it.
I have to type (as root)

su - test

and the prompt changes.

Stephan

---

From: Greg Wooledge <[email-masked]>
Date: Thu, 22 Sep 2016 11:45:19 -0400

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

---

From: Stephan Beck <[email-masked]>
Date: Thu, 22 Sep 2016 16:19:00 +0000

Thanks, Greg.

> not have this restriction.

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

Thanks.

Stephan

---

From: Gene Heskett <[email-masked]>
Date: Wed, 21 Sep 2016 16:43:44 -0400

On Wednesday 21 September 2016 12:24:39 [email-masked] 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:
>
> Basically:
>
>     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
>
> 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

---

From: Greg Wooledge <[email-masked]>
Date: Wed, 21 Sep 2016 10:23:09 -0400

> 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

---

From: Jude DaShiell <[email-masked]>
Date: Thu, 22 Sep 2016 09:42:18 -0400 (EDT)

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 <[email-masked]>
> To: [email-masked]
> Subject: Re: Need a tutorial
> Resent-Date: Wed, 21 Sep 2016 14:23:27 +0000 (UTC)
> Resent-From: [email-masked]
> 

--

---

From: Gene Heskett <[email-masked]>
Date: Thu, 22 Sep 2016 12:17:35 -0400

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

---

From: Gene Heskett <[email-masked]>
Date: Wed, 21 Sep 2016 16:39:24 -0400

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

> 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

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

Thanks.

Cheers, Gene Heskett

---

From: Lars Noodén <[email-masked]>
Date: Thu, 22 Sep 2016 10:44:28 +0300

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

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

---

From: Gene Heskett <[email-masked]>
Date: Thu, 22 Sep 2016 07:09:53 -0400

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

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

> /Lars

Thanks Lars.

Cheers, Gene Heskett

---

From: Lars Noodén <[email-masked]>
Date: Thu, 22 Sep 2016 15:06:34 +0300

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

---

From: Gene Heskett <[email-masked]>
Date: Thu, 22 Sep 2016 12:16:04 -0400

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

> >> As far as the key choices go, DSA is considered deprecated, at
> >> least in the more recent versions:
> >>
> >> 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.
> 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.
>
> 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...

Cheers, Gene Heskett

---

From: [email-masked]
Date: Fri, 23 Sep 2016 03:01:38 +0000 (UTC)

On Thu, 22 Sep 2016, Gene Heskett wrote:

> 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 <[email-masked]>  Tue, 09 Aug 2016 09:56:02 +0000

   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.

---

From: Gene Heskett <[email-masked]>
Date: Thu, 22 Sep 2016 11:55:24 -0400

On Thursday 22 September 2016 08:02:56 [email-masked] wrote:

> On Thu, Sep 22, 2016 at 07:09:53AM -0400, Gene Heskett wrote:
> > > > 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.
> >
> 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. 

> -- t

Thanks, I think this answers the question nicely.

Cheers, Gene Heskett

---

From: Lars Noodén <[email-masked]>
Date: Thu, 22 Sep 2016 19:04:21 +0300

> conversation that it apparently can do the ecdsa. So maybe I shouldn't 

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

---

From: Gene Heskett <[email-masked]>
Date: Thu, 22 Sep 2016 12:32:39 -0400

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

> > conversation that it apparently can do the ecdsa. So maybe I
> > shouldn't worry.
>
Thanks Lars

Cheers, Gene Heskett