Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #172585 > unrolled thread

Need a tutorial

Back to article view | Back to linux.debian.user

Contents

  Need a tutorial Gene Heskett <gheskett@shentel.net> - 2016-09-21 16:20 +0200
    Re: Need a tutorial Greg Wooledge <wooledg@eeg.ccf.org> - 2016-09-21 16:30 +0200
      Re: Need a tutorial Gene Heskett <gheskett@shentel.net> - 2016-09-21 22:40 +0200
        Re: Need a tutorial Lars Noodén <lars.nooden@gmail.com> - 2016-09-22 09:50 +0200
          Re: Need a tutorial <tomas@tuxteam.de> - 2016-09-22 10:50 +0200
          Re: Need a tutorial Gene Heskett <gheskett@shentel.net> - 2016-09-22 13:20 +0200
            Re: Need a tutorial <tomas@tuxteam.de> - 2016-09-22 14:10 +0200
              Re: Need a tutorial Gene Heskett <gheskett@shentel.net> - 2016-09-22 18:00 +0200
                Re: Need a tutorial Lars Noodén <lars.nooden@gmail.com> - 2016-09-22 18:10 +0200
                  Re: Need a tutorial Gene Heskett <gheskett@shentel.net> - 2016-09-22 18:40 +0200
            Re: Need a tutorial Lars Noodén <lars.nooden@gmail.com> - 2016-09-22 14:10 +0200
              Re: Need a tutorial Gene Heskett <gheskett@shentel.net> - 2016-09-22 18:20 +0200
                Re: Need a tutorial davidson@freevolt.org - 2016-09-23 05:10 +0200
      Re: Need a tutorial Jude DaShiell <jdashiel@panix.com> - 2016-09-22 15:50 +0200
        Re: Need a tutorial Gene Heskett <gheskett@shentel.net> - 2016-09-22 18:20 +0200
    Re: Need a tutorial <tomas@tuxteam.de> - 2016-09-21 18:30 +0200
      Re: Need a tutorial Gene Heskett <gheskett@shentel.net> - 2016-09-21 22:50 +0200
      Re: Need a tutorial Stephan Beck <sbeck@secure.mailbox.org> - 2016-09-22 17:40 +0200
        Re: Need a tutorial Greg Wooledge <wooledg@eeg.ccf.org> - 2016-09-22 17:50 +0200
          Re: Need a tutorial Stephan Beck <sbeck@secure.mailbox.org> - 2016-09-22 18:20 +0200
        Re: Need a tutorial Stephan Beck <sbeck@secure.mailbox.org> - 2016-09-22 18:10 +0200
        Re: Need a tutorial "Thomas Schmitt" <scdbackup@gmx.net> - 2016-09-22 18:20 +0200
          Re: Need a tutorial Greg Wooledge <wooledg@eeg.ccf.org> - 2016-09-22 18:20 +0200
            Re: Need a tutorial "Thomas Schmitt" <scdbackup@gmx.net> - 2016-09-22 18:30 +0200
              Re: Need a tutorial Stephan Beck <sbeck@secure.mailbox.org> - 2016-09-22 20:10 +0200
              Re: Need a tutorial Stephan Beck <stebe@mailbox.org> - 2016-09-22 20:30 +0200
          Re: Need a tutorial Stephan Beck <sbeck@secure.mailbox.org> - 2016-09-22 19:00 +0200
        Re: Need a tutorial <tomas@tuxteam.de> - 2016-09-22 19:40 +0200
          sending authorized_keys to localhost from an account being created  with adduser --disabled-password [was] Re: Need a tutorial Stephan Beck <sbeck@secure.mailbox.org> - 2016-09-23 14:40 +0200
            Re: sending authorized_keys to localhost from an account being created with adduser --disabled-password [was] Re: Need a tutorial Greg Wooledge <wooledg@eeg.ccf.org> - 2016-09-23 15:00 +0200
              Re: sending authorized_keys to localhost from an account being  created with adduser --disabled-password [was] Re: Need a tutorial Stephan Beck <sbeck@secure.mailbox.org> - 2016-09-23 16:20 +0200
                Re: sending authorized_keys to localhost from an account being  created with adduser --disabled-password [was] Re: Need a tutorial Stephan Beck <sbeck@secure.mailbox.org> - 2016-09-23 16:20 +0200
              Re: sending authorized_keys to localhost from an account being  created with adduser --disabled-password [was] Re: Need a tutorial Stephan Beck <sbeck@secure.mailbox.org> - 2016-09-23 22:30 +0200
            RESOLVED Re: sending authorized_keys to localhost from an account  being created with adduser --disabled-password [was] Re: Need a tutorial Stephan Beck <sbeck@secure.mailbox.org> - 2016-09-23 15:10 +0200
              Re: RESOLVED Re: sending authorized_keys to localhost from an account  being created with adduser --disabled-password [was] Re: Need a tutorial Stephan Beck <sbeck@secure.mailbox.org> - 2016-09-23 16:00 +0200
            Re: sending authorized_keys to localhost from an account being  created with adduser --disabled-password [was] Re: Need a tutorial <tomas@tuxteam.de> - 2016-09-23 15:20 +0200
              Re: sending authorized_keys to localhost from an account being  created with adduser --disabled-password [was] Re: Need a tutorial Stephan Beck <sbeck@secure.mailbox.org> - 2016-09-23 18:50 +0200
                Re: sending authorized_keys to localhost from an account being  created with adduser --disabled-password [was] Re: Need a tutorial <tomas@tuxteam.de> - 2016-09-24 16:10 +0200
    Re: Need a tutorial Dominique Dumont <dod@debian.org> - 2016-09-22 17:30 +0200
      Re: Need a tutorial Gene Heskett <gheskett@shentel.net> - 2016-09-22 18:40 +0200
        Re: Need a tutorial Greg Wooledge <wooledg@eeg.ccf.org> - 2016-09-22 19:00 +0200
          Re: Need a tutorial Bob Bernstein <poobah@ruptured-duck.com> - 2016-09-22 20:10 +0200
            Re: Need a tutorial "Thomas Schmitt" <scdbackup@gmx.net> - 2016-09-22 21:00 +0200
        Re: Need a tutorial Lars Noodén <lars.nooden@gmail.com> - 2016-09-22 19:10 +0200
        Re: Need a tutorial Dominique Dumont <dod@debian.org> - 2016-09-22 20:20 +0200
          Re: Need a tutorial Greg Wooledge <wooledg@eeg.ccf.org> - 2016-09-22 20:40 +0200
            Re: Need a tutorial Dominique Dumont <dod@debian.org> - 2016-09-22 20:50 +0200
          Re: Need a tutorial Gene Heskett <gheskett@shentel.net> - 2016-09-23 04:30 +0200
            Re: Need a tutorial Dominique Dumont <dod@debian.org> - 2016-09-23 09:20 +0200

Page 1 of 3  [1] 2 3  Next page →

#172585 — Need a tutorial

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>

[toc] | [next] | [standalone]

#172586

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

[toc] | [prev] | [next] | [standalone]

#172601

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

[toc] | [prev] | [next] | [standalone]

#172617

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

[toc] | [prev] | [next] | [standalone]

#172620

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

[toc] | [prev] | [next] | [standalone]

#172629

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

[toc] | [prev] | [next] | [standalone]

#172633

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

[toc] | [prev] | [next] | [standalone]

#172654

On Thursday 22 September 2016 08:02:56 tomas@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 <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [next] | [standalone]

#172658

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

[toc] | [prev] | [next] | [standalone]

#172671

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

[toc] | [prev] | [next] | [standalone]

#172634

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

[toc] | [prev] | [next] | [standalone]

#172664

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

[toc] | [prev] | [next] | [standalone]

#172696

[Multipart message — attachments visible in raw view] — view raw

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 <opal@debian.og>  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.

[toc] | [prev] | [next] | [standalone]

#172639

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 <wooledg@eeg.ccf.org>
> To: debian-user@lists.debian.org
> Subject: Re: Need a tutorial
> Resent-Date: Wed, 21 Sep 2016 14:23:27 +0000 (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
>
>

-- 

[toc] | [prev] | [next] | [standalone]

#172663

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

[toc] | [prev] | [next] | [standalone]

#172594

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

[toc] | [prev] | [next] | [standalone]

#172603

On Wednesday 21 September 2016 12:24:39 tomas@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 <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [next] | [standalone]

#172652

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

[toc] | [prev] | [next] | [standalone]

#172653

On Thu, Sep 22, 2016 at 03:35:00PM +0000, Stephan Beck wrote:
> Sorry, Tomas, it's not Gene, it's me who has a special question
> concerning ssh.
> If you create a new user account ("test"), doing as root
> adduser --disabled-password test
> 
> How can you access this new account to generate an ssh key pair there?

Install sudo if you haven't already.  Then:

sudo -u test bash

Or if you don't want a whole shell:

sudo -u test ssh-keygen [options]

The su program is not as useful for this kind of task, because it
insists on launching the target user's shell, which in some cases is
not a useful interactive command shell (e.g. /bin/false).  sudo does
not have this restriction.

[toc] | [prev] | [next] | [standalone]

#172665

Thanks, Greg.

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

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

Thanks.

Stephan

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | linux.debian.user

csiph-web