Re: ssh-keygen as a regular user

[Eduardo M KALINOWSKI]

On 12/05/2023 09:36, Vincent Lefevre wrote:

On 2023-05-12 18:23:41 +0800, jeremy ardley wrote:

cd

mkdir .ssh

chmod 700 .ssh

ssh-keygen


Is there any reason why ssh-keygen doesn't create a .ssh directory
(with the right permissions) if it doesn't exist yet?


It does, and even let's you know it did:

$ ssh-keygen 
  Generating public/private 
rsa key pair.

Enter file in which to save the key (/home/ekalin/.ssh/id_rsa):
Created directory '/home/ekalin/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/ekalin/.ssh/id_rsa
Your public key has been saved in /home/ekalin/.ssh/id_rsa.pub
...

--
 no BSD fans ?
 Elric: it's hard to be a gamer and a bsd fan :p

Eduardo M KALINOWSKI
edua...@kalinowski.com.br

Re: ssh-keygen as a regular user

[Vincent Lefevre]

On 2023-05-12 18:23:41 +0800, jeremy ardley wrote:
> cd
> 
> mkdir .ssh
> 
> chmod 700 .ssh
> 
> ssh-keygen

Is there any reason why ssh-keygen doesn't create a .ssh directory
(with the right permissions) if it doesn't exist yet?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: ssh-keygen as a regular user

[jeremy ardley]

On 12/5/23 13:50, Jeremy Ardley wrote:

ode[



ssh-keygen usually works better than ssh-keygem

try

cd

mkdir .ssh

ssh-keygen


I now remember some ssh functions check file and directory permissions 
and will fail if not correct


Improved procedure:

cd

mkdir .ssh

chmod 700 .ssh

ssh-keygen

Re: ssh-keygen as a regular user

[Jeremy Ardley]

On 11/5/23 11:22, Igor Korot wrote:


[code]
igor@wxTest:~/wxwidgets$ ssh-keygem
bash: ssh-keygem: command not found
igor@wxTest:~/wxwidgets$ su
Password:
root@wxTest:/home/igor/wxwidgets# apt-get install openssh-client
Reading package lists... Done
Building dependency tree
Reading state information... Done
openssh-client is already the newest version (1:7.9p1-10+deb10u2).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
root@wxTest:/home/igor/wxwidgets# ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): ^C
root@wxTest:/home/igor/wxwidgets#
[/code]

[code]
igor@wxTest:~/wxwidgets$ ls -la ~/.ssh
ls: cannot access '/home/igor/.ssh': No such file or directory
igor@wxTest:~/wxwidgets$
[/code[


ssh-keygen usually works better than ssh-keygem

try

cd

mkdir .ssh

ssh-keygen


--
Jeremy
(Lists)

Re: ssh-keygen as a regular user

[Igor Korot]

Hi,

On Fri, May 12, 2023 at 12:19 AM Geert Stappers  wrote:
>
> On Fri, May 12, 2023 at 12:07:00AM -0500, Igor Korot wrote:
> > Hi, ALL,
> > Is there a reason I can't run "ssh-keygen" as a regular user?
>
> Several  :-)
>
>
> > I am able to do it as "root" though, but I think it shouldn't happen.
> >
> > Can someone shed some light?
>
> Find a better way to open a discussion as a closed question[1].
>
>
> > Thank you.
>
> Start with sharing information how to reproduce[2] the issue.

[code]
igor@wxTest:~/wxwidgets$ ssh-keygem
bash: ssh-keygem: command not found
igor@wxTest:~/wxwidgets$ su
Password:
root@wxTest:/home/igor/wxwidgets# apt-get install openssh-client
Reading package lists... Done
Building dependency tree
Reading state information... Done
openssh-client is already the newest version (1:7.9p1-10+deb10u2).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
root@wxTest:/home/igor/wxwidgets# ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): ^C
root@wxTest:/home/igor/wxwidgets#
[/code]

[code]
igor@wxTest:~/wxwidgets$ ls -la ~/.ssh
ls: cannot access '/home/igor/.ssh': No such file or directory
igor@wxTest:~/wxwidgets$
[/code[

This is on the brand new install.

And I need that to access Git...

Thank you.

>
>
> Groeten
> Geert Stappers
>
> [1] Avoid questions that can be answered with 'yes' or 'no'.
> [2] Describe what is happening at your side. Tell about
> commands used and "errors" seen.
> --
> Silence is hard to parse
>

Re: ssh-keygen as a regular user

[Geert Stappers]

On Fri, May 12, 2023 at 12:07:00AM -0500, Igor Korot wrote:
> Hi, ALL,
> Is there a reason I can't run "ssh-keygen" as a regular user?
 
Several  :-)


> I am able to do it as "root" though, but I think it shouldn't happen.
> 
> Can someone shed some light?
 
Find a better way to open a discussion as a closed question[1].


> Thank you.

Start with sharing information how to reproduce[2] the issue.


Groeten
Geert Stappers

[1] Avoid questions that can be answered with 'yes' or 'no'.
[2] Describe what is happening at your side. Tell about
commands used and "errors" seen.
-- 
Silence is hard to parse

Re: ssh-keygen as a regular user

[Jeremy Ardley]

On 12/5/23 13:07, Igor Korot wrote:

Hi, ALL,
Is there a reason I can't run "ssh-keygen" as a regular user?

I am able to do it as "root" though, but I think it shouldn't happen.


Check the file permissions and ownership of ~/.ssh files ?



--
Jeremy
(Lists)

Re: ssh -N en alleen maar ssh -N toestaan (succes)

[Geert Stappers]

On Tue, Mar 28, 2023 at 09:32:56PM +0200, Paul van der Vlis wrote:
> Op 27-03-2023 om 23:22 schreef Geert Stappers:
> > Op 26-03-2023 om 12:50 schreef Geert Stappers:
> > > 
> > > Uit `man 1 ssh`
> > > 
> > >     -N  Do not execute a remote command.
> > >     This is useful for just forward ports.
> > > 
> > > Nu is `ssh -N` een client kant ding.
> > > 
> > > Hoe aan server kant borgen dat alleen maar port forwarding gebeurd?
> > > 
> > > Ik had gedacht om het dicht te timmeren door aan authorized_keys
> > > op de server wat toe te voegen aan de regel met de pubkey voor
> > > het account dat de `ssh -N` moet gaan doen.
> > > 
> > > Er is "no-port-forwarding"
> > > https://www.ssh.com/academy/ssh/authorized-keys-openssh#no-port-forwarding
> > > maar niet iets als "only-port-forwarding"
> > >  

> > 
> > kunnen oplossen door
> > 
> > command="echo Don\'t do that"
> > 
> > voor de pubkey in ~/.ssh/authorized_keys te zetten. Dat is aan server
> > kant.
> > 
> > Als ik `ssh -N -R :127.0.0.1:22 server` doe, krijg ik de gewenste
> > portforward. Als ik iets zonder `-N` doe, komt er "Don't do that" terug.
> 
> Waarom geen shell die alles weigert?

Poortnummer van de gewenste port forward is langer dan 1025. Om dan de port
open te krijgen is superuserprivilege nodig. Daar ga ik de shell niet van
dichtzetten.

 
> Groet,
> Paul


Groeten
Geert Stappers
-- 
Silence is hard to parse

Re: ssh -N en alleen maar ssh -N toestaan (succes)

[Paul van der Vlis]

Hoi Geert,

Op 27-03-2023 om 23:22 schreef Geert Stappers:

On Mon, Mar 27, 2023 at 12:07:38AM +0200, Paul van der Vlis wrote:

Op 26-03-2023 om 23:51 schreef Paul van der Vlis:

Hoi Geert en anderen,

Op 26-03-2023 om 12:50 schreef Geert Stappers:

Hoi,

Uit `man 1 ssh`

    -N  Do not execute a remote command.
    This is useful for just forward ports.


Nu is `ssh -N` een client kant ding.

Hoe aan server kant borgen dat alleen maar port forwarding gebeurd?



Ik had gedacht om het dicht te timmeren door aan authorized_keys
op de server wat toe te voegen aan de regel met de pubkey voor
het account dat de `ssh -N` moet gaan doen.

Er is "no-port-forwarding"
https://www.ssh.com/academy/ssh/authorized-keys-openssh#no-port-forwarding
maar niet iets als "only-port-forwarding"
    https://www.ssh.com/academy/ssh/authorized-keys-openssh

Wat zien jullie zoal aan mogelijkheden om aan server kant
er voor te zorgen dat SSH client alleen maar een verbinding
voor de portforward maakt, dat shell access niet kan?


Wat ik doe aan de server-kant is /usr/sbin/nologin als shell gebruiken.


Oh, en ik zie dat ik ook dit nog doe in sshd_config:
-
UsePAM no
Match User een,twee
   AllowTcpForwarding remote
   AllowStreamLocalForwarding no
   X11Forwarding no
   PermitTTY no
   PermitEmptyPasswords yes
   PasswordAuthentication yes
-

Kritiek is welkom ;-)
  
Stukje zelfkritiek:

er voor te zorgen dat SSH client alleen maar een verbinding
voor de portforward maakt, dat shell access niet kan?

had

er voor te zorgen dat SSH client alleen maar een verbinding
voor de portforward maakt.

zullen zijn.
Dat aandacht op "alleen maar een verbinding voor portforward" blijft.


Oorspronkelijke vraag heb ik kunnen oplossen door


command="echo Don\'t do that"

voor de pubkey in ~/.ssh/authorized_keys te zetten. Dat is aan server
kant.

Als ik `ssh -N -R :127.0.0.1:22 server` doe, krijg ik de gewenste
portforward. Als ik iets zonder `-N` doe, komt er "Don't do that" terug.


Waarom geen shell die alles weigert?


Ik heb trouwens nog een kleine extra beveiliging in de firewall, mensen
moeten zich eerst ergens aanmelden, dan pas krijgt hun IP toegang.


Met behulp van   from="hun IP"   voor de pubkey in authorized_keys?


Ze moeten eerst ergens naar een webpagina gaan, die triggert een script 
wat de firewall openzet voor hun IP voor een dag. Normaal staat die 
firewall dicht.


Ze kunnen "inloggen" zonder key en zonder paswoord, maar krijgen dus 
"nologin" als prompt. Het is alleen bedoeld voor portforward, via die 
portforward kan ik op hun machine komen voor support.


Groet,
Paul


--
Paul van der Vlis Linux systeembeheer Groningen
https://vandervlis.nl/

Re: ssh -N en alleen maar ssh -N toestaan (succes)

[Geert Stappers]

On Mon, Mar 27, 2023 at 12:07:38AM +0200, Paul van der Vlis wrote:
> Op 26-03-2023 om 23:51 schreef Paul van der Vlis:
> > Hoi Geert en anderen,
> > 
> > Op 26-03-2023 om 12:50 schreef Geert Stappers:
> > > Hoi,
> > > 
> > > Uit `man 1 ssh`
> > > 
> > >    -N  Do not execute a remote command.
> > >    This is useful for just forward ports.
> > > 
> > > 
> > > Nu is `ssh -N` een client kant ding.
> > > 
> > > Hoe aan server kant borgen dat alleen maar port forwarding gebeurd?
> > > 
> > > 
> > > 
> > > Ik had gedacht om het dicht te timmeren door aan authorized_keys
> > > op de server wat toe te voegen aan de regel met de pubkey voor
> > > het account dat de `ssh -N` moet gaan doen.
> > > 
> > > Er is "no-port-forwarding"
> > > https://www.ssh.com/academy/ssh/authorized-keys-openssh#no-port-forwarding
> > > maar niet iets als "only-port-forwarding"
> > >    https://www.ssh.com/academy/ssh/authorized-keys-openssh
> > > 
> > > Wat zien jullie zoal aan mogelijkheden om aan server kant
> > > er voor te zorgen dat SSH client alleen maar een verbinding
> > > voor de portforward maakt, dat shell access niet kan?
> > 
> > Wat ik doe aan de server-kant is /usr/sbin/nologin als shell gebruiken.
> 
> Oh, en ik zie dat ik ook dit nog doe in sshd_config:
> -
> UsePAM no
> Match User een,twee
>   AllowTcpForwarding remote
>   AllowStreamLocalForwarding no
>   X11Forwarding no
>   PermitTTY no
>   PermitEmptyPasswords yes
>   PasswordAuthentication yes
> -
> 
> Kritiek is welkom ;-)
 
Stukje zelfkritiek:
> > > er voor te zorgen dat SSH client alleen maar een verbinding
> > > voor de portforward maakt, dat shell access niet kan?
had
> > > er voor te zorgen dat SSH client alleen maar een verbinding
> > > voor de portforward maakt.
zullen zijn.
Dat aandacht op "alleen maar een verbinding voor portforward" blijft.


Oorspronkelijke vraag heb ik kunnen oplossen door


   command="echo Don\'t do that"

voor de pubkey in ~/.ssh/authorized_keys te zetten. Dat is aan server
kant.

Als ik `ssh -N -R :127.0.0.1:22 server` doe, krijg ik de gewenste
portforward. Als ik iets zonder `-N` doe, komt er "Don't do that" terug.


> Ik heb trouwens nog een kleine extra beveiliging in de firewall, mensen
> moeten zich eerst ergens aanmelden, dan pas krijgt hun IP toegang.

Met behulp van   from="hun IP"   voor de pubkey in authorized_keys?



Groeten
Geert Stappers
-- 
Silence is hard to parse

Re: ssh -N en alleen maar ssh -N toestaan

[Paul van der Vlis]

Op 26-03-2023 om 23:51 schreef Paul van der Vlis:

Hoi Geert en anderen,

Op 26-03-2023 om 12:50 schreef Geert Stappers:

Hoi,

Uit `man 1 ssh`

   -N  Do not execute a remote command.
   This is useful for just forward ports.


Nu is `ssh -N` een client kant ding.

Hoe aan server kant borgen dat alleen maar port forwarding gebeurd?



Ik had gedacht om het dicht te timmeren door aan authorized_keys
op de server wat toe te voegen aan de regel met de pubkey voor
het account dat de `ssh -N` moet gaan doen.

Er is "no-port-forwarding"
   
https://www.ssh.com/academy/ssh/authorized-keys-openssh#no-port-forwarding

maar niet iets als "only-port-forwarding"
   https://www.ssh.com/academy/ssh/authorized-keys-openssh

Wat zien jullie zoal aan mogelijkheden om aan server kant
er voor te zorgen dat SSH client alleen maar een verbinding
voor de portforward maakt, dat shell access niet kan?


Wat ik doe aan de server-kant is /usr/sbin/nologin als shell gebruiken.


Oh, en ik zie dat ik ook dit nog doe in sshd_config:
-
UsePAM no
Match User een,twee
  AllowTcpForwarding remote
  AllowStreamLocalForwarding no
  X11Forwarding no
  PermitTTY no
  PermitEmptyPasswords yes
  PasswordAuthentication yes
-

Kritiek is welkom ;-)

Ik heb trouwens nog een kleine extra beveiliging in de firewall, mensen 
moeten zich eerst ergens aanmelden, dan pas krijgt hun IP toegang.


Groet,
Paul



--
Paul van der Vlis Linux systeembeheer Groningen
https://vandervlis.nl/

Re: ssh -N en alleen maar ssh -N toestaan

[Paul van der Vlis]

Hoi Geert en anderen,

Op 26-03-2023 om 12:50 schreef Geert Stappers:

Hoi,

Uit `man 1 ssh`

   -N  Do not execute a remote command.
   This is useful for just forward ports.


Nu is `ssh -N` een client kant ding.

Hoe aan server kant borgen dat alleen maar port forwarding gebeurd?



Ik had gedacht om het dicht te timmeren door aan authorized_keys
op de server wat toe te voegen aan de regel met de pubkey voor
het account dat de `ssh -N` moet gaan doen.

Er is "no-port-forwarding"
   https://www.ssh.com/academy/ssh/authorized-keys-openssh#no-port-forwarding
maar niet iets als "only-port-forwarding"
   https://www.ssh.com/academy/ssh/authorized-keys-openssh

Wat zien jullie zoal aan mogelijkheden om aan server kant
er voor te zorgen dat SSH client alleen maar een verbinding
voor de portforward maakt, dat shell access niet kan?


Wat ik doe aan de server-kant is /usr/sbin/nologin als shell gebruiken.

Groet,
Paul


--
Paul van der Vlis Linux systeembeheer Groningen
https://vandervlis.nl/

Re: ssh-add after graphical login

[Yassine Chaouche]

Le 3/23/23 à 17:53, Erwan David a écrit :

I create a shell script ~/bin/start-session.sh in this script I have the command 
ssh-add < -

in System Settings > Startup and Shutdown > autostart I add this script as a 
login script


Thanks Erwan,
that's what I ended up doing.
the
 ssh-add < -
line looks dubious to me.
It seems like you're redirecting standard input to standard input,
that is to say it doesn't do much.

Best,

--
yassine -- sysadm
+213-779 06 06 23
http://about.me/ychaouche
Looking for side gigs.

Re: ssh-add after graphical login

[Erwan David]

Le 23/03/2023 à 09:42, Yassine Chaouche a écrit :

Hello all,

I'd like something to run ssh-add right after I login to my desktop
(KDE).
ssh-add needs to prompt me for my passphrase,
and doesn't need any privileges.

What are my options?

Best,



I  do this way :

I create a shell script ~/bin/start-session.sh in this script I have the 
command ssh-add < -


in System Settings > Startup and Shutdown > autostart I add this script 
as a login script

Re: ssh-add after graphical login

[Vincent Lefevre]

On 2023-03-23 09:42:53 +0100, Yassine Chaouche wrote:
> I'd like something to run ssh-add right after I login to my desktop
> (KDE).
> ssh-add needs to prompt me for my passphrase,
> and doesn't need any privileges.
> 
> What are my options?

FYI, with zsh, I'm using wrappers so that I don't need to run ssh-add
directly: it is run automatically when needed by ssh:

  https://www.vinc17.net/unix/zsh-ssh-utils.tar.xz

This is mainly based on code I wrote in 2003, with some improvements
since.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: ssh-add after graphical login

[Jeffrey Walton]

On Thu, Mar 23, 2023 at 8:57 AM Greg Wooledge  wrote:
>
> On Thu, Mar 23, 2023 at 08:53:48AM -0400, Jeffrey Walton wrote:
> > On Thu, Mar 23, 2023 at 4:43 AM Yassine Chaouche
> >  wrote:
> > >
> > > I'd like something to run ssh-add right after I login to my desktop
> > > (KDE).
> > > ssh-add needs to prompt me for my passphrase,
> > > and doesn't need any privileges.
> > >
> > > What are my options?
> >
> > You can remove the passphrase from the key. Then your agents can use
> > the key unattended (without prompting you).
>
> While this is true, it's a really awful suggestion...

Agreed. OP wanted options.

Jeff

Re: ssh-add after graphical login

[Greg Wooledge]

On Thu, Mar 23, 2023 at 08:53:48AM -0400, Jeffrey Walton wrote:
> On Thu, Mar 23, 2023 at 4:43 AM Yassine Chaouche
>  wrote:
> >
> > I'd like something to run ssh-add right after I login to my desktop
> > (KDE).
> > ssh-add needs to prompt me for my passphrase,
> > and doesn't need any privileges.
> >
> > What are my options?
> 
> You can remove the passphrase from the key. Then your agents can use
> the key unattended (without prompting you).

While this is true, it's a really awful suggestion.  Removing the
passphrase from the key means that if the key is ever stolen, the
thief can use it to impersonate you in any context that accepts this
key.

Re: ssh-add after graphical login

[Jeffrey Walton]

On Thu, Mar 23, 2023 at 4:43 AM Yassine Chaouche
 wrote:
>
> I'd like something to run ssh-add right after I login to my desktop
> (KDE).
> ssh-add needs to prompt me for my passphrase,
> and doesn't need any privileges.
>
> What are my options?

You can remove the passphrase from the key. Then your agents can use
the key unattended (without prompting you).

Removing the passphrase from the key is no different than storing the
key in a KeyChain without protection so the key can be used unattended
by an agent.

Jeff

Re: ssh-add after graphical login

[Yassine Chaouche]

Le 3/23/23 à 12:24, Greg Wooledge a écrit :

 ssh-add 

Ah!
this is what I was missing!
the whole problem was how to ssh-add in a graphical way,
now that I have found a way,
I can maybe put it in a script inside the XDG Autostart directory.
This might leave more room for the ssh-agent to start,
and the whole desktop to launch
(KDE is somewhat slow on startup)

Best,

--
yassine -- sysadm
+213-779 06 06 23
http://about.me/ychaouche
Looking for side gigs.

Re: ssh-add after graphical login

[Yassine Chaouche]

Le 3/23/23 à 12:56, basti a écrit :

The ssh config inside ~/.ssh/ has an option 'AddKeysToAgent'.
Why you don't use this?

For example:

Host *
    ControlMaster auto
    ControlPath /run/user/%i/%r@%h-%p
    IdentityFile ~/.ssh/id_rsa
    ControlPersist 3600
    User root
    AddKeysToAgent yes



This is actually an excellent suggestion,
as it also greatly simplifies how I login to remote hosts!
the command line use to be
ssh user@host -p port

now all I need to do is:
ssh host

Thanks again basti!

Best,

--
yassine -- sysadm
+213-779 06 06 23
http://about.me/ychaouche
Looking for side gigs.

Re: ssh-add after graphical login

[Michel Verdier]

Le 23 mars 2023 Greg Wooledge a écrit :

> The only part I'm unsure of, for you, is how to ensure that this runs
> *after* your ssh agent has already been started.  I don't know how ssh
> agent startup is handled with Display Manager logins, since I don't use
> a DM, and I just start ssh-agent myself, right before running ssh-add.

I let ssh-agent call gpg-agent. So I do nothing in .ssh/config and in my
.xsession I put :

unset SSH_AGENT_PID
SSH_ASKPASS=/usr/bin/ssh-askpass
SSH_AUTH_SOCK=$(gpgconf --list-dirs agent-ssh-socket)
export SSH_ASKPASS SSH_AUTH_SOCK

gpg-agent is launched via systemd. In .gnupg/gpg-agent.conf I put :

pinentry-program /usr/bin/pinentry-gnome3
enable-ssh-support

Re: ssh-add after graphical login

[basti]

The ssh config inside ~/.ssh/ has an option 'AddKeysToAgent'.
Why you don't use this?

For example:

Host *
   ControlMaster auto
   ControlPath /run/user/%i/%r@%h-%p
   IdentityFile ~/.ssh/id_rsa
   ControlPersist 3600
   User root
   AddKeysToAgent yes

See man ssh_config

On 23.03.23 09:42, Yassine Chaouche wrote:

Hello all,

I'd like something to run ssh-add right after I login to my desktop
(KDE).
ssh-add needs to prompt me for my passphrase,
and doesn't need any privileges.

What are my options?

Best,

Re: ssh-add after graphical login

[Greg Wooledge]

On Thu, Mar 23, 2023 at 09:42:53AM +0100, Yassine Chaouche wrote:
> I'd like something to run ssh-add right after I login to my desktop
> (KDE).
> ssh-add needs to prompt me for my passphrase,
> and doesn't need any privileges.
> 
> What are my options?

On Debian you can create a ~/.xsessionrc file which is executed by
/bin/sh when starting an X session, either by DM login or startx.

Inside that file, you should be able to run:

ssh-add 

Re: ssh bug known_hosts?

[Greg Wooledge]

On Thu, Mar 02, 2023 at 09:52:35AM +0800, Jeremy Ardley wrote:
> On 2/3/23 05:51, Greg Wooledge wrote:
> > unicorn:~$ namei -l ~/.ssh/config
> > f: /home/greg/.ssh/config
> > drwxr-xr-x root root /
> > drwxr-xr-x root root home
> > drwxr-xr-x greg greg greg
> > drwxr-xr-x greg greg .ssh
> > -rw-r--r-- greg greg config
> > 
> My ~/.ssh files are for the most part even more restrictive
> 
> -rw--- 1 jeremy jeremy  446 Mar  2 08:51 config
> -rw--- 1 jeremy jeremy 2602 Dec 11 11:47 id_rsa
> -rw-r--r-- 1 jeremy jeremy  567 Dec 11 11:47 id_rsa.pub

You are not providing enough information.

The permissions of ALL THE DIRECTORIES IN THE PATH to the files matter
too.

It's an extremely common failure for someone to have, for example, the
group write bit on the /home directory (or $HOME), and for this to cause
ssh to refuse to read various files.

Re: ssh bug known_hosts?

[Jeffrey Walton]

On Wed, Mar 1, 2023 at 8:53 PM Jeremy Ardley  wrote:
> [...]
> However I've found the cause of the problem, but not necessarily
> resolved the bug.
>
> For some reason on my journey /etc/ssh/ssh_config had acquired
>
> UserKnownHostsFile /etc/ssh/ssh_known_hosts
>
> changing to
>
> #   UserKnownHostsFile /etc/ssh/ssh_known_hosts

That should probably be GlobalKnownHostsFile, not UserKnownHostsFile.
>From the the ssh_config(5) man page at
https://manpages.debian.org/bullseye/openssh-client/ssh_config.5.en.html
:

GlobalKnownHostsFile

Specifies one or more files to use for the global
host key database, separated by whitespace.
The default is /etc/ssh/ssh_known_hosts,
/etc/ssh/ssh_known_hosts2.

But not setting GlobalKnownHostsFile gets you the default, which
appears to be the same as you specified in your config file.

Jeff

Re: ssh bug known_hosts?

[Jeremy Ardley]

On 2/3/23 05:51, Greg Wooledge wrote:

On Wed, Mar 01, 2023 at 02:43:38PM -0700, Charles Curley wrote:

On Thu, 2 Mar 2023 03:48:49 +0800
jeremy ardley  wrote:


2. The known hosts file used is /etc/ssh/known_hosts rather that
~/.ssh/known_hosts - which causes a permissions error

I am not seeing that, for either root or my regular non-root user.

You indicated you created your ~/.ssh/config as shown in your email. I
would check the configuration files in /etc/ssh.

It would be worth checking the permissions and ownerships.

unicorn:~$ namei -l ~/.ssh/config
f: /home/greg/.ssh/config
drwxr-xr-x root root /
drwxr-xr-x root root home
drwxr-xr-x greg greg greg
drwxr-xr-x greg greg .ssh
-rw-r--r-- greg greg config


My ~/.ssh files are for the most part even more restrictive

-rw--- 1 jeremy jeremy  446 Mar  2 08:51 config
-rw--- 1 jeremy jeremy 2602 Dec 11 11:47 id_rsa
-rw-r--r-- 1 jeremy jeremy  567 Dec 11 11:47 id_rsa.pub

However I've found the cause of the problem, but not necessarily 
resolved the bug.


For some reason on my journey /etc/ssh/ssh_config had acquired

   UserKnownHostsFile /etc/ssh/ssh_known_hosts

changing to

#   UserKnownHostsFile /etc/ssh/ssh_known_hosts

stops this behaviour.

--
Jeremy
(Lists)

Re: ssh bug known_hosts?

[jeremy ardley]

On 2/3/23 05:52, Jeffrey Walton wrote:

On Wed, Mar 1, 2023 at 2:49 PM jeremy ardley  wrote:

I may have found a bug in openssh.
[...]
I have created a ~/.ssh/config file with contents

Host jeremy_client
  HostName client.example.com
  User jeremy
  IdentityFile ~/.ssh/com.example.jeremy.id_rsa

Does ssh_config(5) do Bash parameter expansion. That is, is the tilde
(~) expanded? I don't see it listed in the man page at
https://linux.die.net/man/5/ssh_config .


In the IdentityFile section in your reference, they say :

"Specifies a file from which the user's RSA or DSA authentication 
identity is read. The default is /~/.ssh/identity/ for protocol version 
1, and /~/.ssh/id_rsa/ and /~/.ssh/id_dsa/ for protocol version 2. 
Additionally, any identities represented by the authentication agent 
will be used for authentication.


The file name may use the tilde syntax to refer to a user's home 
directory or one of the following escape characters: '%d' (local user's 
home directory), '%u' (local user name), '%l' (local host name), '%h' 
(remote host name) or '%r' (remote user name). "


The sad part is I thought I was getting a handle on configuring openssh 
using ldap and certificates. The multitude  of options there say I'm 
nowhere near!


--

Jeremy

Re: ssh bug known_hosts?

[Greg Wooledge]

On Wed, Mar 01, 2023 at 04:52:57PM -0500, Jeffrey Walton wrote:
> On Wed, Mar 1, 2023 at 2:49 PM jeremy ardley  wrote:
> >
> > I may have found a bug in openssh.
> > [...]
> > I have created a ~/.ssh/config file with contents
> >
> > Host jeremy_client
> >  HostName client.example.com
> >  User jeremy
> >  IdentityFile ~/.ssh/com.example.jeremy.id_rsa
> 
> Does ssh_config(5) do Bash parameter expansion. That is, is the tilde
> (~) expanded? I don't see it listed in the man page at
> https://linux.die.net/man/5/ssh_config .

In the bullseye ssh_config(5) man page:

 Arguments to IdentityFile may use the tilde syntax to refer to a
 user's home directory or the tokens described in the TOKENS sec‐
 tion.

The linux.die.net copy has similar wording, but is from an older version,
so it should not be used as an authority.  If you need an online man page,
there's  which will redirect to
a man page from the current stable release.

Re: ssh bug known_hosts?

[Jeffrey Walton]

On Wed, Mar 1, 2023 at 2:49 PM jeremy ardley  wrote:
>
> I may have found a bug in openssh.
> [...]
> I have created a ~/.ssh/config file with contents
>
> Host jeremy_client
>  HostName client.example.com
>  User jeremy
>  IdentityFile ~/.ssh/com.example.jeremy.id_rsa

Does ssh_config(5) do Bash parameter expansion. That is, is the tilde
(~) expanded? I don't see it listed in the man page at
https://linux.die.net/man/5/ssh_config .

Jeff

Re: ssh bug known_hosts?

[Greg Wooledge]

On Wed, Mar 01, 2023 at 02:43:38PM -0700, Charles Curley wrote:
> On Thu, 2 Mar 2023 03:48:49 +0800
> jeremy ardley  wrote:
> 
> > 2. The known hosts file used is /etc/ssh/known_hosts rather that 
> > ~/.ssh/known_hosts - which causes a permissions error
> 
> I am not seeing that, for either root or my regular non-root user.
> 
> You indicated you created your ~/.ssh/config as shown in your email. I
> would check the configuration files in /etc/ssh.

It would be worth checking the permissions and ownerships.

unicorn:~$ namei -l ~/.ssh/config
f: /home/greg/.ssh/config
drwxr-xr-x root root /
drwxr-xr-x root root home
drwxr-xr-x greg greg greg
drwxr-xr-x greg greg .ssh
-rw-r--r-- greg greg config

Either that, or something like:

unicorn:~$ ls -ld / /home ~ ~/.ssh ~/.ssh/config
drwxr-xr-x  29 root root  4096 Jan 24 07:17 //
drwxr-xr-x  14 root root  4096 Jan 11  2018 /home/
drwxr-xr-x 227 greg greg 53248 Mar  1 15:01 /home/greg/
drwxr-xr-x   3 greg greg  4096 Apr 18  2021 /home/greg/.ssh/
-rw-r--r--   1 greg greg   525 Apr 25  2015 /home/greg/.ssh/config

I find the second one more readable, but the first one is definitely
easier to type.  Either way, make sure the permissions are *correct*,
which is to say, there should not be a world-write or group-write bit
on any line of the output.

Re: ssh bug known_hosts?

[Jeffrey Walton]

On Wed, Mar 1, 2023 at 2:49 PM jeremy ardley  wrote:
>
> I may have found a bug in openssh.
>
> I raise it here as the ssh mailing list is actually a newsgroup that
> no-one seems to use.

You might give comp.security.openssh a try:
https://groups.google.com/g/comp.security.ssh . That is the general
user mailing list. I've always gotten an answer from the list.

Here is the bug reporting page: https://www.openssh.com/report.html .
It sounds like you should use openssh-unix-...@mindrot.org. Archives
are available at https://marc.info/?l=openssh-unix-dev .

Jeff

Re: ssh bug known_hosts?

[Charles Curley]

On Thu, 2 Mar 2023 03:48:49 +0800
jeremy ardley  wrote:

> 2. The known hosts file used is /etc/ssh/known_hosts rather that 
> ~/.ssh/known_hosts - which causes a permissions error

I am not seeing that, for either root or my regular non-root user.

You indicated you created your ~/.ssh/config as shown in your email. I
would check the configuration files in /etc/ssh.

> ssh -V
> OpenSSH_8.4p1 Debian-5+deb11u1, OpenSSL 1.1.1n  15 Mar 2022

Bullseye, I take it.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: ssh pub.key

[Jeffrey Walton]

On Mon, Feb 20, 2023 at 8:21 PM  wrote:
>
> Normaly i use the same ssh.pub.key for different servers;

Does this mean you use the same SSH keys for your user account, and
SSH into servers with the one key pair? If so, I think this is
expected.

Or do you mean all the servers/sshd use the same SSH key pair?

> but when i use
> it with a Debian totally encripted 4th option of the installer; i am not
> able to login!

What is the 4th option of the installer?

> Is tgere something different in that case?

In case you have an encrypted home directory, see
https://stephenreescarter.net/encrypted-home-directories-ssh-key-authentication/
.

Otherwise, we probably need more information about your setup. Or at
least I need more information.

Jeff

Re: ssh pub.key

[john doe]

On 2/21/23 02:05, latin...@vcn.bc.ca wrote:

Hello

Normaly i use the same ssh.pub.key for different servers; but when i use
it with a Debian totally encripted 4th option of the installer; i am not
able to login!

Is tgere something different in that case?




- How so?
- Do you see anything in the log?
- What error(s) do you get?

--
John Doe

Re: ssh -X authentication with sudo

[martin f krafft]

I really didn't mean to kick this off ;)

Original poster: instead of the GUI programm, I recommend you try 
cfdisk. It's not "graphical", but it has a nice UI, and it can do 
everything you need. `sudo cfdisk /dev/device` and you're going to 
be much happier.


--
 .''`.   martin f. krafft  @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems
 
"the question of whether computers can think

 is like the question of whether submarines can swim."
   -- edsgar w. dijkstra

Re: ssh -X authentication with sudo

[Charles Curley]

On Wed, 05 Oct 2022 10:59:47 -0400
The Wanderer  wrote:

> > Sorry, must have missed the memo that made an apparently-typo-ed
> > double question mark into an emoticon.  
> 
> It's not an emoticon. There is a convention, which if I'm not mistaken
> goes back decades and originates well before emoticons (and perhaps
> even *icons* in anything like the modern sense) were ever a thing,
> that "??" indicates not just a question but one asked with an air of
> incredulity.

Chess notation (specifically descriptive notation, for the pedantic)
uses one to three question marks to indicate incredulity, and one to
three exclamation points (!) to indicate surprise, or compliment the
player on a really good move. Those conventions go back at least to the
mid-19th century.

Before anyone protests that he doesn't play chess, so I shouldn't expect
him to know this, I don't. This is explanatory. He has the opportunity
to learn something.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: ssh -X authentication with sudo

[The Wanderer]

On 2022-10-05 at 11:21, debian-u...@howorth.org.uk wrote:

>> On 2022-10-05 at 10:48, debian-u...@howorth.org.uk wrote:

>>> Perhaps you could explain why the debian manpage specifically
>>> says it must be run as root then?
>> 
>> What is "it" here? That is, what is the specific program to whose
>> man page you're referring? (Identifying the exact man page would
>> probably be best, for that purpose.)
> 
> Perhaps you should read the thread since I already posted its 
> invocation.

Looking all the way back at the original post which started the thread,
I find a single mention of 'linssid', in a dense block of other lines.

I had, indeed, missed that. (Although I have, in fact, read every
message posted thus far in the thread.)

The man page I'm finding (online, since I don't have the package
installed and don't care to install it just to check this) does discuss
running the program as root via xhost - but only as a fallback from
running it via gksudo as a more ordinary user.

There's a distinction between running as root and running with root
access, but it may not be an important one for this purpose.

Graphical programs which need to be run with root access are
comparatively rare, and may arguably be poorly designed, but this does
appear to be one of them. I'd wonder whether making the program suid
root could also be a viable option, but that might just bring in the
worst of both worlds, so it might not be worth pursuing.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: ssh -X authentication with sudo

[debian-user]

> On 2022-10-05 at 10:48, debian-u...@howorth.org.uk wrote:
> 
> >> On Wed, Oct 05, 2022 at 10:30:37AM +0100,
> >> debian-u...@howorth.org.uk wrote:  
> 
> >>> Yes, I am running a GUI as root. It won't run as normal user.  
> >> 
> >> You seem to have missed the implied criticism and/or incredulity. 
> >> Hint: look at the double question mark.  
> > 
> > Sorry, must have missed the memo that made an apparently-typo-ed
> > double question mark into an emoticon.  
> 
> It's not an emoticon. There is a convention, which if I'm not mistaken
> goes back decades and originates well before emoticons (and perhaps
> even *icons* in anything like the modern sense) were ever a thing,
> that "??" indicates not just a question but one asked with an air of
> incredulity.

I still missed the memo. So I didn't miss something I didn't know, and
can't find any evidence for.

> >> Switching to ssh -X root@ with a pubkey would actually *improve*
> >> your security, not that you really need a lot of security on your
> >> home LAN.
> >> on a widescreen, placing them on the side, as wm2 and wmx do,
> >> would save valuable vertical pixels. Of course that still leaves
> >> you running GUI admin programs as root, which is something you'll
> >> have to wean yourself from at your own pace.  
> > 
> > Perhaps you could explain why the debian manpage specifically says
> > it must be run as root then?  
> 
> What is "it" here? That is, what is the specific program to whose man
> page you're referring? (Identifying the exact man page would probably
> be best, for that purpose.)

Perhaps you should read the thread since I already posted its
invocation.

Re: ssh -X authentication with sudo

[The Wanderer]

On 2022-10-05 at 10:48, debian-u...@howorth.org.uk wrote:

>> On Wed, Oct 05, 2022 at 10:30:37AM +0100,
>> debian-u...@howorth.org.uk wrote:

>>> Yes, I am running a GUI as root. It won't run as normal user.
>> 
>> You seem to have missed the implied criticism and/or incredulity. 
>> Hint: look at the double question mark.
> 
> Sorry, must have missed the memo that made an apparently-typo-ed
> double question mark into an emoticon.

It's not an emoticon. There is a convention, which if I'm not mistaken
goes back decades and originates well before emoticons (and perhaps even
*icons* in anything like the modern sense) were ever a thing, that "??"
indicates not just a question but one asked with an air of incredulity.

>> Switching to ssh -X root@ with a pubkey would actually *improve*
>> your security, not that you really need a lot of security on your
>> home LAN.
>> 
>> Of course that still leaves you running GUI admin programs as
>> root, which is something you'll have to wean yourself from at your
>> own pace.
> 
> Perhaps you could explain why the debian manpage specifically says
> it must be run as root then?

What is "it" here? That is, what is the specific program to whose man
page you're referring? (Identifying the exact man page would probably be
best, for that purpose.)

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: ssh -X authentication with sudo

[debian-user]

> On Wed, Oct 05, 2022 at 10:30:37AM +0100, debian-u...@howorth.org.uk
> wrote:
> > > Regarding the following, written by "debian-u...@howorth.org.uk"
> > > on 2022-10-04 at 13:52 Uhr +0100:  
> > > >PS as you surmised, I don't really want root ssh access.
> > > 
> > > But you are running GUIs as root??  
> > 
> > Yes, I am running a GUI as root. It won't run as normal user.  
> 
> You seem to have missed the implied criticism and/or incredulity.
> Hint: look at the double question mark.

Sorry, must have missed the memo that made an apparently-typo-ed double
question mark into an emoticon.

> Your clinging to the ridiculous superstition that "direct root access
> with a pubkey on a LAN is bad, but sudo is good" while simultaneously
> running admin GUIs as root (which is *demonstrably* a bad idea) is
> unfortunate, but sadly common.

If you want to persuade me to lose such a ridiculous superstition, then
providing a link to some educational source that supports your
assertion would be helpful.

> Switching to ssh -X root@ with a pubkey would actually *improve* your
> security, not that you really need a lot of security on your home LAN.
> 
> Of course that still leaves you running GUI admin programs as root,
> which is something you'll have to wean yourself from at your own pace.

Perhaps you could explain why the debian manpage specifically says it
must be run as root then?

Re: ssh -X authentication with sudo

[Brad Rogers]

On Wed, 05 Oct 2022 15:52:58 +0300
Anssi Saari  wrote:

Hello Anssi,

>I only run one, GParted. As I don't mess around with partitions that
>often I want a clear GUI tool that hopefully shows me if I'm about to do
>something catastrophical. IOW, I don't see an alternative.

AFAIR, you run GParted as a user and at the appropriate time, the user
is required to enter a password(1)(2).  Maybe their own, or maybe root's.
It depends on how the system is set up.

(1)  The Policykit dependency is an indication that root privileges are
required, and that GParted can/will escalate to root (or at least user
with admin privileges) as required.

(2)  It's /years/ since I ran GParted, but KDE Partition Manager - which
does the same job - requires escalation at start up.

-- 
 Regards  _
 / )  "The blindingly obvious is never immediately apparent"
/ _)rad   "Is it only me that has a working delete key?"
You're all invited to a party, you don't even have to come
Get The Funk Out - Extreme


pgpIF4bDjKQZE.pgp
Description: OpenPGP digital signature

Re: ssh -X authentication with sudo

[Anssi Saari]

martin f krafft  writes:

> But you are running GUIs as root??

I only run one, GParted. As I don't mess around with partitions that
often I want a clear GUI tool that hopefully shows me if I'm about to do
something catastrophical. IOW, I don't see an alternative.

Re: ssh -X authentication with sudo

[Greg Wooledge]

On Wed, Oct 05, 2022 at 10:30:37AM +0100, debian-u...@howorth.org.uk wrote:
> > Regarding the following, written by "debian-u...@howorth.org.uk" on
> > 2022-10-04 at 13:52 Uhr +0100:
> > >PS as you surmised, I don't really want root ssh access.  
> > 
> > But you are running GUIs as root??
> 
> Yes, I am running a GUI as root. It won't run as normal user.

You seem to have missed the implied criticism and/or incredulity.
Hint: look at the double question mark.

Your clinging to the ridiculous superstition that "direct root access with
a pubkey on a LAN is bad, but sudo is good" while simultaneously running
admin GUIs as root (which is *demonstrably* a bad idea) is unfortunate,
but sadly common.

Switching to ssh -X root@ with a pubkey would actually *improve* your
security, not that you really need a lot of security on your home LAN.

Of course that still leaves you running GUI admin programs as root, which
is something you'll have to wean yourself from at your own pace.

Re: ssh -X authentication with sudo

[The Wanderer]

On 2022-10-05 at 05:30, debian-u...@howorth.org.uk wrote:

>> Regarding the following, written by "debian-u...@howorth.org.uk"
>> on 2022-10-04 at 13:52 Uhr +0100:
>> 
>>> PS as you surmised, I don't really want root ssh access.
>> 
>> But you are running GUIs as root??
> 
> Yes, I am running a GUI as root. It won't run as normal user.

Is this a matter of logging in via the text-mode console and then
running 'startx', and getting errors from that when not root?

There are ways around that, involving the xserver-xorg-legacy package,
and possibly a couple of local configuration changes. I have had my last
few Debian systems set up with that package and the needed changes, and
I routinely run startx from the console as a non-root user and have
things work.

It's been long enough that I don't remember what the needed changes
*are*, if indeed there are any beyond just installing that package - but
I can assure you that if this is the approach you're taking, running X
as non-root is indeed possible.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: ssh -X authentication with sudo

[debian-user]

> Regarding the following, written by "debian-u...@howorth.org.uk" on
> 2022-10-04 at 13:52 Uhr +0100:
> >PS as you surmised, I don't really want root ssh access.  
> 
> But you are running GUIs as root??

Yes, I am running a GUI as root. It won't run as normal user.

Re: ssh -X authentication with sudo

[martin f krafft]

Regarding the following, written by "debian-u...@howorth.org.uk" on 2022-10-04 
at 13:52 Uhr +0100:

PS as you surmised, I don't really want root ssh access.


But you are running GUIs as root??

--
 .''`.   martin f. krafft  @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems
 
may the bluebird of happiness twiddle your bits.

Re: ssh -X authentication with sudo

[Jeremy Ardley]

On 4/10/22 8:52 pm, debian-u...@howorth.org.uk wrote:


To use the display without ssh root login. ssh as normal user to
host. Then

echo $DISPLAY

su -

export DISPLAY=localhost:10 (or whatever your logged in user DISPLAY
is set to)

xauth add $(xauth -f ~/.Xauthority list | tail -1)

xhost

Thanks, that worked after a little fiddling. Firstly, /root/.Xauthority
didn't exist, so xauth complained. Touching the file sorted that. And
secondly, the .Xauthority file contained three lines and the one I need
was in the middle :( I suppose that was a result of previous fiddling
about I'd done resulting in extra logins. But removing the last entry
in the file (a) didn't immediately crash anything and (b) let xauth
work next time I ran it :) So success, and many thanks! Oh and





I tested this before I responded. However in my system I can also log in 
as root and run graphics applications. I did this  before checking the 
workaround.


I assume when I ran graphics first as root, the .Xauthority file was 
created so I didn't get the error you had later. Plus the new 
.Xauthority file wouldn't have had any garbage in it.


--
Jeremy



OpenPGP_signature
Description: OpenPGP digital signature

Re: ssh -X authentication with sudo

[debian-user]

> On 4/10/22 7:39 pm, Greg Wooledge wrote:
> > Change the sshd_config to allow direct root logins.
> > Then do ssh -X r...@debian.box.
> >
> > If you're the paranoid type, or if the Debian system is exposed to
> > the public Internet, then make sure you only permit root logins
> > when using pubkey authentication, not password.  Then set up an RSA
> > pubkey for your direct root login.
> >  
> 
> To use the display without ssh root login. ssh as normal user to
> host. Then
> 
> echo $DISPLAY
> 
> su -
> 
> export DISPLAY=localhost:10 (or whatever your logged in user DISPLAY
> is set to)
> 
> xauth add $(xauth -f ~/.Xauthority list | tail -1)
> 
> xhost

Thanks, that worked after a little fiddling. Firstly, /root/.Xauthority
didn't exist, so xauth complained. Touching the file sorted that. And
secondly, the .Xauthority file contained three lines and the one I need
was in the middle :( I suppose that was a result of previous fiddling
about I'd done resulting in extra logins. But removing the last entry
in the file (a) didn't immediately crash anything and (b) let xauth
work next time I ran it :) So success, and many thanks! Oh and

sudo su - of course.

PS as you surmised, I don't really want root ssh access.

Re: ssh -X authentication with sudo

[Jeremy Ardley]

On 4/10/22 7:39 pm, Greg Wooledge wrote:

Change the sshd_config to allow direct root logins.
Then do ssh -X r...@debian.box.

If you're the paranoid type, or if the Debian system is exposed to the
public Internet, then make sure you only permit root logins when using
pubkey authentication, not password.  Then set up an RSA pubkey for your
direct root login.



To use the display without ssh root login. ssh as normal user to host. Then

echo $DISPLAY

su -

export DISPLAY=localhost:10 (or whatever your logged in user DISPLAY is 
set to)


xauth add $(xauth -f ~/.Xauthority list | tail -1)

xhost



--
Jeremy



OpenPGP_signature
Description: OpenPGP digital signature

Re: ssh -X authentication with sudo

[Greg Wooledge]

On Tue, Oct 04, 2022 at 12:31:23PM +0100, Dave Howorth wrote:
> I have a machine running debian that I access using ssh. I use the -X
> with ssh and can successfully run e.g. xeyes on the debian machine
> showing the display on my local machine. But now I want to run a
> graphical program that needs to run as root on the debian machine
> while displaying on my local machine.

Change the sshd_config to allow direct root logins.

Then do ssh -X r...@debian.box.

If you're the paranoid type, or if the Debian system is exposed to the
public Internet, then make sure you only permit root logins when using
pubkey authentication, not password.  Then set up an RSA pubkey for your
direct root login.

Re: ssh certificate authentication: can one user and one server certificate work for any number of users or servers on a LAN?

[Dan Ritter]

rhkra...@gmail.com wrote: 
> I am (still) rather confused about using ssh certificate authentication.
> 
> I am confused about a variety of specifics, but the biggie is this: I have 
> the 
> idea that I can create one user certificate and one server (host) 
> certificate, 
> and use that for any number of users and servers on a LAN.

Doing so is a lot like telling all the users that their password
is now "swordfish".

You could do that, but it defeats common sense.

Here's what's going on:

* You (root on many systems) create a certificate authority.
This is a Big Secret.

* You use the Big Secret to sign a Trust Me certificate

* You install the Trust Me cert on all your SSH servers.

* You tell the SSH servers that anyone who can successfully
negotiate a key exchange with the Trust Me cert is an
authorized user -- log them in.

* You use the Trust Me certificate to sign a user-cert
for each user. The user cert says "My username is rhkramer, you
can trust me."

* rhkramer can now log in to any host that believes in your
Trust Me cert, by presenting the user-cert which the Trust Me
certificate can decode.

Pro:
You manage one cert per SSH server, not a pair per user

Cons:
You must keep and properly distribute a CRL, certificate
revocation list
You must keep track of expiration dates on the user-certs
You must re-issue user-certs before the expirations
You must have automated machinery to manage the user-certs
You must properly protect your Big Secret
You must keep everything running

-dsr-

Re: SSH resources, specifically on certificates (certificate authentication)

[David Christensen]

On 7/15/22 05:32, Curt wrote:


The question I ask myself preliminarily, before delving further into
the matter, is whether certificate-based SSH authentication is
appropriate for a home LAN with three users.



+1


I decided SSH with publickey authentication and passphrase keys were 
plenty for my SOHO network.  "SSH Mastery" by Lucas is the relevant title:


https://mwl.io/nonfiction/tools#ssh


That said, I have a Hurricane Electric domain hosting account and I have 
a Linode VPS with the Unibuiti Networks UniFi Controller (installed by a 
Linode community "stack script").  Both include LetsEncrypt certificates 
with automatic renewal for their https service.  Hurricane Electric 
administers all of their services; I just use them.  Linode administers 
their hypervisor.  I administer and use the VPS.



David

Re: SSH resources, specifically on certificates (certificate authentication)

[rhkramer]

On Friday, July 15, 2022 08:49:01 AM to...@tuxteam.de wrote:
> On Fri, Jul 15, 2022 at 12:32:35PM -, Curt wrote:
> > The question I ask myself preliminarily, before delving further into
> > the matter, is whether certificate-based SSH authentication is
> > appropriate for a home LAN with three users.
> 
> Definitely not.

Getting ahead of myself (because my next question / source of puzzlement will 
get into that), I will say "maybe".

-- 
rhk

If you reply: snip, snip, and snip again; leave attributions; avoid top 
posting; and keep it "on list".  (Oxford comma included at no charge.)  If you 
change topics, change the Subject: line. 

A picture is worth a thousand words -- divide by 10 for each minute of video 
(or audio) or create a transcript and edit it to 10% of the original.

3 more surprising (to me) things about ssh (was: Re: SSH resources, specifically on certificates (certificate authentication))

[rhkramer]

Thanks for the response, and to dsr as well.  I won't really ask a question 
here, but I will make some comments -- not sure how / where to fit them in -- 
will try to intersperse below.  Or maybe I'll just top post them here:

Surprise 2:

Another surprising thing to me (with the evolution of the surprise) -- my 
initial objective (until I came across certificates) was to learn about public 
key(pair) authentication with the intent to allow passwordless ssh between 
computers on my LAN.  It was in the course of digging into that that I learned 
about things like the Diffie-Hellman key exchange and the use of a symmetric 
encryption algorithm for the exchange of bulk / payload data.

Then I got to thinking that if ssh uses a symmetric algorithm for exchange of 
bulk data in (well, after) public key authentication, it probably does the 
same (that is, use symmetric encryption (with a shared secret encryption key)) 
after any other method of authentication, and that it probably also uses Diffie-
Hellman key exchange (maybe with different inputs) in those other methods of 
authentication.

(I'm assuming this is also the case for gssapi (one variation being Kerberos) 
authentication, in which I have absolutely no interest, at least at present.)

Your post makes me much more confident that is the case.

Surprise 3:

Maybe it should not have been a surprise, but ssh turns out to be much more 
complex and flexible than I expected -- I've been trying to think of the best 
word to describe it and have been thinking of it as sort of a meta-protocol 
instead of just a protocol.  I say that for a number of reasons (some that 
don't really justify the use of the prefix meta, but)

   * Variations of ssh, either within one implementation (e.g., openssh) or 
between implementations of ssh (by other vendors) can use a wide variety of 
actual encryption protocols (e.g., AES-128, AES-192, AES-256, RSA, ecDSA, 
ed25???. and a variety of others.  And, next week, when somebody implements a 
new variation of ssh, they might use other protocols / algorithms.  (Of 
course, some backward compatibility and handshaking is required so different 
implementations can talk to each other (to the extent possible) (one example 
is the openssh versions 1.0, 2.00, and 1.99, which I won't explain atm).

   * I mentioned it already in the previous bullet, but the other point I was 
going to make is that other vendors / implementors can implement variations of 
ssh which can use different encryption protocols (but again, need means of 
backward compatitbility / handshaking or such for inter-operability between 
implementations).

Surprise 4: 

Even Diffie-Hellman is (or can be) more complex than I recall it being 
described 
in the Wikipedia article (but I may have forgotten some of what I read there).

For example, in the variation used in public key(pair) authentication, in 
addition to the expected user and server public keypairs, there are things 
like a salt, and multiple iterations of some algorithm / process, and even a(n 
optional?) second set of public keypairs (ephemeral public keypairs, used once 
and thrown away, iiuc).  This (the additional ephemeral keypairs) might be 
only in the variation of Diffie-Hellman known as triple Diffie-Hellman (3-DH).)

(In at least one source I found, 3-DH is the thing that mentioned as providing 
forward security, but I think the bigger point is, as dsr pointed out, the 
generation of new session keys for each new "session" (which, afaict, can be 
done with things like a new salt (which I think is a random number) or a 
different number of iterations of some process (and that number of iterations 
might also be a random number), i.e., 3-DH is not necessarily required for 
forward security).

And to elaborate a little (without me knowing the details) even in ssh 
(simple) password authentication, some variation of Diffie-Hellman (or Diffie-
Hellman using different inputs -- maybe using the "host" public keypairs for 
both the client and server machines instead of using the server public keypair 
and a user public keypair (as in public key authenttication) with the user 
password thrown into the mix somewhere.

I don't care too much about the actual details, it is enough for me (for now) 
to know (or at least think I know) that even the process for (simple) password 
authentication is fairly complex, secure(, and, (incidently) almost certainly 
uses some variation of Diffie-Hellman).

(Oh, I could also mention that sometimes variations of Diffie-Hellman are 
referred to as being of different groups, some being more secure than others.  
I won't get into that at all -- I mean, I don't think I need to know any 
details.  Oh, and sometimes, iiuc, that is referred to as Diffie-Hellman Group 
Exchange instead of Diffie-Hellman Key Exchange, which seems like at least a 
little bit of a misnomer to me.)

Comments / clarifications / corrections welcome.

Maybe my next post will pose the big question I 

Re: SSH resources, specifically on certificates (certificate authentication)

[tomas]

On Fri, Jul 15, 2022 at 12:32:35PM -, Curt wrote:
> On 2022-07-14, Dan Ritter  wrote:
> >
> > If you've got a very large organization, you may want to support
> > the infrastructure to generate new SSH certs for people daily,
> > with expiration dates of 24 hours. Then you need to make sure
> > that mechanism is working perfectly and has appropriate
> > redundancy, so that you don't accidentally lock out the whole
> > organization tomorrow.
> 
> The question I ask myself preliminarily, before delving further into
> the matter, is whether certificate-based SSH authentication is
> appropriate for a home LAN with three users.

Definitely not.

OTOH -- would you like those managing your thousand-plus hosts and
tens of thousands of IDs to learn "on the living organism"?

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: SSH resources, specifically on certificates (certificate authentication)

[Curt]

On 2022-07-14, Dan Ritter  wrote:
>
> If you've got a very large organization, you may want to support
> the infrastructure to generate new SSH certs for people daily,
> with expiration dates of 24 hours. Then you need to make sure
> that mechanism is working perfectly and has appropriate
> redundancy, so that you don't accidentally lock out the whole
> organization tomorrow.

The question I ask myself preliminarily, before delving further into
the matter, is whether certificate-based SSH authentication is
appropriate for a home LAN with three users.


> -dsr-
>
>

Re: SSH resources, specifically on certificates (certificate authentication)

[Dan Ritter]

to...@tuxteam.de wrote: 
> See, asymmetrical encryption (e.g. RSA, Elliptic Curve) is far too expensive
> to use on bulk data, so it typically is used to encrypt a key (generated on
> the spot), called "session key". The latter is used to symmetrically (e.g.
> AES) encrypt the bulk data. You use that style typically in the deferred
> case.
> 
> Perhaps there's even a security advantage in that, since the session key,
> as being used for more data gives a potential cryptanalist more material
> to chew on: then just the session key would be compromised, and you throw
> that away for the next round. I don't know.

The systems that throw it away and redo the DH exchange frequently
are said to have "perfect forward security": an attacker who gains one
session key doesn't get the next session key.

-dsr-

Re: SSH resources, specifically on certificates (certificate authentication)

[tomas]

On Thu, Jul 14, 2022 at 08:01:19PM -0400, rhkra...@gmail.com wrote:

[...]

> I'll probably start with a post to describe one of the most surprising things 
> I learned about ssh so far -- to jump ahead and spoil it, it turns out that 
> public key encryption is not used for the exchange of the real "user" / 
> payload data, but instead a symmetric (one of a variety, iiuc) encryption 
> algorithm, with the same encryption key used by both the client and server, 
> but developed by each independently and never exchanged "over the wire".

This is standard for public key cryptography, be it "interactive style"
(e.g. SSH, TLS, where both parties exchange message) or "deferred style"
(e.g. PGP/GPG, where one party prepares an encrypted message ahead of time
for the other to decrypt).

See, asymmetrical encryption (e.g. RSA, Elliptic Curve) is far too expensive
to use on bulk data, so it typically is used to encrypt a key (generated on
the spot), called "session key". The latter is used to symmetrically (e.g.
AES) encrypt the bulk data. You use that style typically in the deferred
case.

Perhaps there's even a security advantage in that, since the session key,
as being used for more data gives a potential cryptanalist more material
to chew on: then just the session key would be compromised, and you throw
that away for the next round. I don't know.

> This is done by a process named Diffie_Hellman key exchange, and the 
> Wikipedia 
> article on that (URL below) explains it quite well, with one example done in 
> terms of colors of paint (i.e., that people without an extensive background 
> in 
> math or cryptography can understand).

Diffie Hellman is only used in the "interactive" case above, to establish
a secure path without having exchanged /any/ keys before; after that, you
have to do a key exchange to make sure you are talking to whom you think
you are (that's the "authenticity" part of the scheme [1]). You can't use
Diffie-Hellman for mails or encrypted files/disks, since the other party
has gone to sleep when you find the "message" :-)

With D-H you can have confidentiality with some random second party. Just
think of that. It makes me dizzy after all that years ;-)

But in both cases (interactive, deferred), you agree on a session key for
symmetric encryption to carry the brunt. It's so much faster than everything
else that it's not even funny, and it is cryptographically much better
understood.

Cheers

[1] Remember that the whole thing has three goals
   confidentiality - no one else can read in on the message
   authenticity - you are talking to whom you think you are
   integriry - nothing has tampered with the message on its way

-- 
tomás


signature.asc
Description: PGP signature

Re: SSH resources, specifically on certificates (certificate authentication)

[David Wright]

On Thu 14 Jul 2022 at 10:00:29 (-0400), Frank Pikelner wrote:

> SSH certificate authentication is not complicated and has many
> advantages. Some organizations use SSH certificates to provide limited
> access for admins to servers. In my opinion using SSH certificates is
> preferred to just using ssh keys. There are a number of guides on how
> to implement ssh certificates - if you are unable to locate, ping me
> directly and I may have a document I wrote for myself a while back.

Please consider yourself pinged. (3 Jun 2021)

Cheers,
David.

Re: SSH resources, specifically on certificates (certificate authentication)

[rhkramer]

Intentionally top posting.

Thanks for the reply!

I'm thinking of two or three paths forward -- one is to give up on this, but 
I've invested a lot of calandar days (and non-"spare" manhours so far, so I 
don't want to do that.

Another is to make another pass through some of what I consider the best 
documentation I've found so far and see if I can puzzle out the answers and 
such that I'm looking for.

The third is to ask questions on this list, and I think that is at least part 
of what I'll try.  Some of my questions (and even the entire subject) will 
probably involve some fairly wordy introduction to the questions.

Sorry about that.

I'll probably start with a post to describe one of the most surprising things 
I learned about ssh so far -- to jump ahead and spoil it, it turns out that 
public key encryption is not used for the exchange of the real "user" / 
payload data, but instead a symmetric (one of a variety, iiuc) encryption 
algorithm, with the same encryption key used by both the client and server, 
but developed by each independently and never exchanged "over the wire".

This is done by a process named Diffie_Hellman key exchange, and the Wikipedia 
article on that (URL below) explains it quite well, with one example done in 
terms of colors of paint (i.e., that people without an extensive background in 
math or cryptography can understand).

[[https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange][Diffie–
Hellman key exchange - Wikipedia]]

I guess this serves as that first post I mentioned.  No questions so far.

Nothing new below this line.

On Thursday, July 14, 2022 11:35:50 AM to...@tuxteam.de wrote:
> As someone else said, I agree that the certificate way is quite a bit more
> complex than just distributing public keys. It'll play out its advantages
> if you have many servers /and/ many users -- the disadvantages are clear:
> you have to manage your CA (where the root of trust resides), /and/ your
> servers need regular access to the CRLs (certificate revocation lists) for
> the case anything gets compromised (of course, you could do whithout, but
> then, why use certs at all?).
> 
> An alternative for a more central and orderly key distribution is to put
> pubkeys in some form of directory service (say, LDAP). In our $COMPANY
> (sub-100s of servers, sub-50 of IDs) we chose that path. Newer ssh servers
> can delegate the authorized_keys to a script (i.e. the server doesn't
> look things up in a file but runs a small program/shell script which is
> supposed to output something looking like the authorized_keys file).
> 
> OTOH, if all you want is to learn how this cert stuff works, that's
> *always* a strong reason to try!
> 
> Cheers

-- 
rhk

If you reply: snip, snip, and snip again; leave attributions; avoid top 
posting; and keep it "on list".  (Oxford comma included at no charge.)  If you 
change topics, change the Subject: line. 

A picture is worth a thousand words -- divide by 10 for each minute of video 
(or audio) or create a transcript and edit it to 10% of the original.

Re: SSH resources, specifically on certificates (certificate authentication)

[David Christensen]

On 7/14/22 09:59, rhkra...@gmail.com wrote:

On Wednesday, July 13, 2022 07:58:14 PM David Christensen wrote:

Buy and read "TLS Mastery" by Lucas:

https://mwl.io/nonfiction/networking#tls


Replying off list intentionally:  AFAIK, TLS doesn't have much, if anything, to
do with ssh certificates.  It may be (probably is) relevant to ssl certificates.



Modern encryption is a large and complex subject that is constantly 
evolving.  I seem to recall that you stated that you were having a hard 
time finding current and coherent information.  I buy Lucas books 
because he provides both.  I think you would find the book useful.




Maybe I should reply on list "for the record".



I am replying to the list.



Thanks for your reply, and have a good day!



Same to you.  :-)


David

Re: SSH resources, specifically on certificates (certificate authentication)

[rhkramer]

On Wednesday, July 13, 2022 07:09:33 PM Jeremy Ardley wrote:
> I understand that certificate based SSH authentication has problems with
> overall security management on a network. Password only has similar
> problems.

I'm not sure it has any more problems than ssh public key authentication, 
maybe even less, but that is part of what I'm trying to learn / determine.

> The correct solution seems to be a centrally managed authentication
> server but I haven't found any simple guide to implementing that in the
> Debian environment. Is there any useful tutorial available?

tomas makes one suggestion in a later post to this thread.

Another way that I think is along the lines you're talking about is referred 
to as gssapi (iirc) (at least in some of the man pages), of which Kerberos is 
one variety (iiuc) -- there are apparently other varieties.

I don't plan on digging into that. ;-)

-- 
rhk

If you reply: snip, snip, and snip again; leave attributions; avoid top 
posting; and keep it "on list".  (Oxford comma included at no charge.)  If you 
change topics, change the Subject: line. 

A picture is worth a thousand words -- divide by 10 for each minute of video 
(or audio) or create a transcript and edit it to 10% of the original.

Re: SSH resources, specifically on certificates (certificate authentication)

[tomas]

On Thu, Jul 14, 2022 at 08:55:34AM -0400, rhkra...@gmail.com wrote:
> 
> 
> dsr, Thanks for the reply!
> 
> Like I said, I think I went down a rabbit hole, and I wish I had realized 
> that 
> before I went there.

As someone else said, I agree that the certificate way is quite a bit more
complex than just distributing public keys. It'll play out its advantages
if you have many servers /and/ many users -- the disadvantages are clear:
you have to manage your CA (where the root of trust resides), /and/ your
servers need regular access to the CRLs (certificate revocation lists) for
the case anything gets compromised (of course, you could do whithout, but
then, why use certs at all?).

An alternative for a more central and orderly key distribution is to put
pubkeys in some form of directory service (say, LDAP). In our $COMPANY
(sub-100s of servers, sub-50 of IDs) we chose that path. Newer ssh servers
can delegate the authorized_keys to a script (i.e. the server doesn't
look things up in a file but runs a small program/shell script which is
supposed to output something looking like the authorized_keys file).

OTOH, if all you want is to learn how this cert stuff works, that's
*always* a strong reason to try!

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: SSH resources, specifically on certificates (certificate authentication)

[Frank Pikelner]

On Thu, Jul 14, 2022 at 8:56 AM  wrote:
>
> 
>
> dsr, Thanks for the reply!
>
> Like I said, I think I went down a rabbit hole, and I wish I had realized that
> before I went there.
>
> I've invested quite a few calendar days (and "spare" manhours) in trying to
> figure this out, so I'm not quite ready to give up.
>
> I do have some ideas (an idea) for another pass through some of the
> documentation that might clarify what I need / want to know, but, especially
> if that doesn't work, I may write a WikiLearn page or two that mainly just
> warns about the rabbit hole.
>
> I'm almost certain I will be back with some specific questions that maybe you
> or someone else on the list can answer.
>
> Thanks again!
>
> On Thursday, July 14, 2022 02:11:30 AM Dan Ritter wrote:
> > Dan Purgert wrote:
> ...
> > > > > On Jul 13, 2022, rhkra...@gmail.com wrote:
> > > > > > I seem to have gone down a rabbit hole.
>
> > Right, the problem is in everything to support that: running a
> > certificate authority in a secure manner is extremely
> > non-trivial. Running it in a secure and reliable manner is even
> > more non-trivial.
> >
> > In general, I don't recommend it. Consider this:
> >
> > - an SSH certificate has a date on which it will expire. When
> > that day comes, it will stop functioning. If you don't have
> > infrastructure to remind you to re-issue this in advance, you
> > may be locked out of whatever you are trying to access.
> >
> > - conversely, if you want to revoke an SSH certificate before
> > the expiration date, you need to maintain and distribute a
> > revocation list of all the certs that you no longer approve of.
> > Miss a machine and the old cert is still valid up to the
> > expiration date.
> >
> > For most people in most cases, those are not the behaviors that
> > they want.
> >
> > > I've never seen this implemented in any place I've worked in
> > > the last 2 decades (granted, I "only" have said 2 decades of
> > > "professional" experience); rather they've always used either (a) keys,
> > > or (b) password + RSA Token (or other 2FA / TOTP mechanism)
> >
> > And the reason is that those fit what people want more closely
> > than the cert mechanism.
> >
> > If you've got a very large organization, you may want to support
> > the infrastructure to generate new SSH certs for people daily,
> > with expiration dates of 24 hours. Then you need to make sure
> > that mechanism is working perfectly and has appropriate
> > redundancy, so that you don't accidentally lock out the whole
> > organization tomorrow.
> >
> > -dsr-
>
> --


SSH certificate authentication is not complicated and has many
advantages. Some organizations use SSH certificates to provide limited
access for admins to servers. In my opinion using SSH certificates is
preferred to just using ssh keys. There are a number of guides on how
to implement ssh certificates - if you are unable to locate, ping me
directly and I may have a document I wrote for myself a while back.

Best,

Frank

Re: SSH resources, specifically on certificates (certificate authentication)

[rhkramer]

dsr, Thanks for the reply!

Like I said, I think I went down a rabbit hole, and I wish I had realized that 
before I went there.

I've invested quite a few calendar days (and "spare" manhours) in trying to 
figure this out, so I'm not quite ready to give up.

I do have some ideas (an idea) for another pass through some of the 
documentation that might clarify what I need / want to know, but, especially 
if that doesn't work, I may write a WikiLearn page or two that mainly just 
warns about the rabbit hole.

I'm almost certain I will be back with some specific questions that maybe you 
or someone else on the list can answer.

Thanks again!

On Thursday, July 14, 2022 02:11:30 AM Dan Ritter wrote:
> Dan Purgert wrote:
...
> > > > On Jul 13, 2022, rhkra...@gmail.com wrote:
> > > > > I seem to have gone down a rabbit hole.

> Right, the problem is in everything to support that: running a
> certificate authority in a secure manner is extremely
> non-trivial. Running it in a secure and reliable manner is even
> more non-trivial.
> 
> In general, I don't recommend it. Consider this:
> 
> - an SSH certificate has a date on which it will expire. When
> that day comes, it will stop functioning. If you don't have
> infrastructure to remind you to re-issue this in advance, you
> may be locked out of whatever you are trying to access.
> 
> - conversely, if you want to revoke an SSH certificate before
> the expiration date, you need to maintain and distribute a
> revocation list of all the certs that you no longer approve of.
> Miss a machine and the old cert is still valid up to the
> expiration date.
> 
> For most people in most cases, those are not the behaviors that
> they want.
> 
> > I've never seen this implemented in any place I've worked in
> > the last 2 decades (granted, I "only" have said 2 decades of
> > "professional" experience); rather they've always used either (a) keys,
> > or (b) password + RSA Token (or other 2FA / TOTP mechanism)
> 
> And the reason is that those fit what people want more closely
> than the cert mechanism.
> 
> If you've got a very large organization, you may want to support
> the infrastructure to generate new SSH certs for people daily,
> with expiration dates of 24 hours. Then you need to make sure
> that mechanism is working perfectly and has appropriate
> redundancy, so that you don't accidentally lock out the whole
> organization tomorrow.
> 
> -dsr-

-- 
rhk

If you reply: snip, snip, and snip again; leave attributions; avoid top 
posting; and keep it "on list".  (Oxford comma included at no charge.)  If you 
change topics, change the Subject: line. 

A picture is worth a thousand words -- divide by 10 for each minute of video 
(or audio) or create a transcript and edit it to 10% of the original.

Re: SSH resources, specifically on certificates (certificate authentication)

[Dan Ritter]

Dan Purgert wrote: 
> On Jul 13, 2022, David Wright wrote:
> > On Wed 13 Jul 2022 at 18:40:18 (-0400), Dan Purgert wrote:
> > > On Jul 13, 2022, rhkra...@gmail.com wrote:
> > > > I seem to have gone down a rabbit hole.
> > > > 
> > > > I want(ed?) to set up ssh on my LAN using certificate authentication, 
> > > > and am 
> > > > having a lot of trouble finding the information I need / would like to 
> > > > have.
> > > 
> > > Which is what, exactly?  Other than the "active mailing list" you
> > > mentioned in a snipped segment.
> > > 
> > > SSH with cert-auth is pretty trivial to implement on most distros:
> > > 
> > > 1. install openssh-server (if not already installed) on SERVER (the
> > > machine you will connect to)
> > > 2. on the CLIENT (machine you will connect from), run ssh-keygen to
> > > generate a new ssh keypair.  For example --  ssh-keygen -t ed25519 -f
> > > keyfile -- will generate a new ED25519-based keypair ("keyfile" and
> > > "keyfile.pub").
> > > 3. copy the content of keyfile.pub to $HOME/.ssh/authorized_keys on the
> > > SERVER machine
> > > 4. try logging into SERVER with your key (e.g. ssh -i keyfile
> > > user@SERVER) 
> > > 
> > > For "best security" repeat steps 2-4 on all CLIENT machines to create
> > > individual client keys -- just make sure to APPEND to authorized_keys.
> > 
> > That's what I do, but that's /key/ authentication, not cert.
> > (Search for "certificate" in   man ssh-keygen   to see what's
> > involved with certificates.) I'm afraid I'm not up to speed
> > on that topic.
> 
> *sigh* indeed, I crossed my thinking. :(
> 
> Should be basically the same -- at least the manpages for ssh and
> ssh-keygen cover it pretty well...
> 
>  ssh-keygen -s /path/to/ca -I keyid /peth/to/user_public
> 
> sshd apparently needs a "cert-authority" parameter set at start-time, so
> that it knows the signing CA for the certs, and then you (apparently)
> configure authorized_keys in the same manner.  
 
Right, the problem is in everything to support that: running a
certificate authority in a secure manner is extremely
non-trivial. Running it in a secure and reliable manner is even
more non-trivial.

In general, I don't recommend it. Consider this:

- an SSH certificate has a date on which it will expire. When
that day comes, it will stop functioning. If you don't have
infrastructure to remind you to re-issue this in advance, you
may be locked out of whatever you are trying to access.

- conversely, if you want to revoke an SSH certificate before
the expiration date, you need to maintain and distribute a
revocation list of all the certs that you no longer approve of.
Miss a machine and the old cert is still valid up to the
expiration date.

For most people in most cases, those are not the behaviors that
they want. 


> I've never seen this implemented in any place I've worked in
> the last 2 decades (granted, I "only" have said 2 decades of
> "professional" experience); rather they've always used either (a) keys,
> or (b) password + RSA Token (or other 2FA / TOTP mechanism)

And the reason is that those fit what people want more closely
than the cert mechanism.

If you've got a very large organization, you may want to support
the infrastructure to generate new SSH certs for people daily,
with expiration dates of 24 hours. Then you need to make sure
that mechanism is working perfectly and has appropriate
redundancy, so that you don't accidentally lock out the whole
organization tomorrow.

-dsr-

Re: SSH resources, specifically on certificates (certificate authentication)

[Dan Purgert]

On Jul 13, 2022, David Wright wrote:
> On Wed 13 Jul 2022 at 18:40:18 (-0400), Dan Purgert wrote:
> > On Jul 13, 2022, rhkra...@gmail.com wrote:
> > > I seem to have gone down a rabbit hole.
> > > 
> > > I want(ed?) to set up ssh on my LAN using certificate authentication, and 
> > > am 
> > > having a lot of trouble finding the information I need / would like to 
> > > have.
> > 
> > Which is what, exactly?  Other than the "active mailing list" you
> > mentioned in a snipped segment.
> > 
> > SSH with cert-auth is pretty trivial to implement on most distros:
> > 
> > 1. install openssh-server (if not already installed) on SERVER (the
> > machine you will connect to)
> > 2. on the CLIENT (machine you will connect from), run ssh-keygen to
> > generate a new ssh keypair.  For example --  ssh-keygen -t ed25519 -f
> > keyfile -- will generate a new ED25519-based keypair ("keyfile" and
> > "keyfile.pub").
> > 3. copy the content of keyfile.pub to $HOME/.ssh/authorized_keys on the
> > SERVER machine
> > 4. try logging into SERVER with your key (e.g. ssh -i keyfile
> > user@SERVER) 
> > 
> > For "best security" repeat steps 2-4 on all CLIENT machines to create
> > individual client keys -- just make sure to APPEND to authorized_keys.
> 
> That's what I do, but that's /key/ authentication, not cert.
> (Search for "certificate" in   man ssh-keygen   to see what's
> involved with certificates.) I'm afraid I'm not up to speed
> on that topic.

*sigh* indeed, I crossed my thinking. :(

Should be basically the same -- at least the manpages for ssh and
ssh-keygen cover it pretty well...

 ssh-keygen -s /path/to/ca -I keyid /peth/to/user_public

sshd apparently needs a "cert-authority" parameter set at start-time, so
that it knows the signing CA for the certs, and then you (apparently)
configure authorized_keys in the same manner.  

I've never seen this implemented in any place I've worked in
the last 2 decades (granted, I "only" have said 2 decades of
"professional" experience); rather they've always used either (a) keys,
or (b) password + RSA Token (or other 2FA / TOTP mechanism)

-- 
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1  E067 6D65 70E5 4CE7 2860


signature.asc
Description: PGP signature

Re: SSH resources, specifically on certificates (certificate authentication)

[David Christensen]

On 7/13/22 13:11, rhkra...@gmail.com wrote:

I seem to have gone down a rabbit hole.

I want(ed?) to set up ssh on my LAN using certificate authentication, and am
having a lot of trouble finding the information I need / would like to have.

I won't go into much detail now, but I didn't realize how big a subject ssh
is, and although I'm finding a lot of resources of various sorts (man pages,
articles, tutorials), I'm also finding a lot of incomplete, confusing,
conflicting, out-of-date, and, sometimes, afaict incorrect information.

I'd like to find an active mailing list that provides support for ssh.  Of the
mailing lists I've found, one went defunct in 2001, another in 2011, and the
Debian ssh list is for developers / maintainers, not for support.

I didn't (and don't want to read a book (but with all the other stuff I've
read, I probably could have read a book or two by now), I have found an online
book that was published in 2001 and does not address certificates (certificates
are listed in the index, but they are talking about ssl certificates).

My intention was to learn how to use certificates for ssh authentication on my
small LAN, and then, in view of how confusing the documentation I found seemed
to be, to try to write a wiki page (or several) (on WikiLearn) to try to be as
clear as possible.  (And, in addition to not wanting to read a book, nor do I
want to write one.)

So, I should mention some of the resources I've found (I've looked at a bunch,
and won't try to list them here), the two best I've found so far are:

* 
[[https://dev.to/gvelrajan/how-to-configure-and-setup-ssh-certificates-for-
ssh-authentication-b52][How to configure and setup SSH certificates for SSH
authentication]]

* [[https://smallstep.com/blog/use-ssh-certificates/][If you’re not using
SSH certificates you’re doing SSH wrong]]

If I can't find an ssh specific mailing list that is willing to consider support
questions, I'll probably start posting some of my questions here.

Thanks!



Buy and read "TLS Mastery" by Lucas:

https://mwl.io/nonfiction/networking#tls


David

Re: SSH resources, specifically on certificates (certificate authentication)

[David Wright]

On Wed 13 Jul 2022 at 18:40:18 (-0400), Dan Purgert wrote:
> On Jul 13, 2022, rhkra...@gmail.com wrote:
> > I seem to have gone down a rabbit hole.
> > 
> > I want(ed?) to set up ssh on my LAN using certificate authentication, and 
> > am 
> > having a lot of trouble finding the information I need / would like to have.
> 
> Which is what, exactly?  Other than the "active mailing list" you
> mentioned in a snipped segment.
> 
> SSH with cert-auth is pretty trivial to implement on most distros:
> 
> 1. install openssh-server (if not already installed) on SERVER (the
> machine you will connect to)
> 2. on the CLIENT (machine you will connect from), run ssh-keygen to
> generate a new ssh keypair.  For example --  ssh-keygen -t ed25519 -f
> keyfile -- will generate a new ED25519-based keypair ("keyfile" and
> "keyfile.pub").
> 3. copy the content of keyfile.pub to $HOME/.ssh/authorized_keys on the
> SERVER machine
> 4. try logging into SERVER with your key (e.g. ssh -i keyfile
> user@SERVER) 
> 
> For "best security" repeat steps 2-4 on all CLIENT machines to create
> individual client keys -- just make sure to APPEND to authorized_keys.

That's what I do, but that's /key/ authentication, not cert.
(Search for "certificate" in   man ssh-keygen   to see what's
involved with certificates.) I'm afraid I'm not up to speed
on that topic.

Cheers,
David.

Re: SSH resources, specifically on certificates (certificate authentication)

[Jeremy Ardley]

On 14/7/22 6:40 am, Dan Purgert wrote:

On Jul 13, 2022, rhkra...@gmail.com wrote:

I seem to have gone down a rabbit hole.

I want(ed?) to set up ssh on my LAN using certificate authentication, and am
having a lot of trouble finding the information I need / would like to have.

Which is what, exactly?  Other than the "active mailing list" you
mentioned in a snipped segment.

SSH with cert-auth is pretty trivial to implement on most distros:



I understand that certificate based SSH authentication has problems with 
overall security management on a network. Password only has similar 
problems.


The correct solution seems to be a centrally managed authentication 
server but I haven't found any simple guide to implementing that in the 
Debian environment. Is there any useful tutorial available?




--

Jeremy



OpenPGP_signature
Description: OpenPGP digital signature

Re: SSH resources, specifically on certificates (certificate authentication)

[Dan Purgert]

On Jul 13, 2022, rhkra...@gmail.com wrote:
> I seem to have gone down a rabbit hole.
> 
> I want(ed?) to set up ssh on my LAN using certificate authentication, and am 
> having a lot of trouble finding the information I need / would like to have.

Which is what, exactly?  Other than the "active mailing list" you
mentioned in a snipped segment.

SSH with cert-auth is pretty trivial to implement on most distros:

1. install openssh-server (if not already installed) on SERVER (the
machine you will connect to)
2. on the CLIENT (machine you will connect from), run ssh-keygen to
generate a new ssh keypair.  For example --  ssh-keygen -t ed25519 -f
keyfile -- will generate a new ED25519-based keypair ("keyfile" and
"keyfile.pub").
3. copy the content of keyfile.pub to $HOME/.ssh/authorized_keys on the
SERVER machine
4. try logging into SERVER with your key (e.g. ssh -i keyfile
user@SERVER) 

For "best security" repeat steps 2-4 on all CLIENT machines to create
individual client keys -- just make sure to APPEND to authorized_keys.


-- 
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1  E067 6D65 70E5 4CE7 2860


signature.asc
Description: PGP signature

Fwd: Re: SSH timeout logoff don't work!

[Conti Stefano]

Loïc Grenié thanks!! Work well! I was trying to do a script exactly
like your script! Thanks and again thanks! 

--- Begin Message ---
Hi,

Le mar. 21 juin 2022 à 10:14, Conti Stefano  a écrit :

> Hello! In My Debian 11 SSH timeout logoff not work! I must put in .bashrc
> of my user: TMOUT=600 to loogut after 10 minutes. Work, of course, but
> close all bash terminal!
>
> This is my sshd_config with info for timeout:
>
> TCPKeepAlive no
> ClientAliveInterval 600
> ClientAliveCountMax 0
>
> Any suggest?
>

 Maybe

if [ "$(ps -o comm $PPID | tail -1)" = sshd ]; then TMOUT=600; fi

   This is not foolproof, but it should work if you do not abuse the system.

  Hope this helps,

 Loïc
--- End Message ---

Re: SSH timeout logoff don't work!

[Loïc Grenié]

Hi,

Le mar. 21 juin 2022 à 10:14, Conti Stefano  a écrit :

> Hello! In My Debian 11 SSH timeout logoff not work! I must put in .bashrc
> of my user: TMOUT=600 to loogut after 10 minutes. Work, of course, but
> close all bash terminal!
>
> This is my sshd_config with info for timeout:
>
> TCPKeepAlive no
> ClientAliveInterval 600
> ClientAliveCountMax 0
>
> Any suggest?
>

 Maybe

if [ "$(ps -o comm $PPID | tail -1)" = sshd ]; then TMOUT=600; fi

   This is not foolproof, but it should work if you do not abuse the system.

  Hope this helps,

 Loïc

Re: : SSH timeout logoff don't work!

[didier . gaumet]

Le mardi 21 juin 2022 à 23:40 +0200, didier gaumet a écrit :

[...]
> - if you want to restrict the time of ssh connection and are in
> position to modify the ssh command they use (an alias in their bashrc
> for example?), perhaps you can try to force the ssh -o option with
> the ConnectTimeout parameter (see ssh manpage). I have never done it
> myself, so I don't know if it can solve your problem.

Too quick to post: I just checked the ssh_config manpage and this
ConnectTimeout parameter is only relative to the time to establish the
connection, so no cigar.

Re: : SSH timeout logoff don't work!

[didier gaumet]

Le mardi 21 juin 2022 à 12:52 +0200, Conti Stefano a écrit :
> If I put ClientAliveCountMax 1 with ClientAliveInterval 600 timeout
> is 1200 inmy Debian 11. I have try all combinations but at the moment
> nothing happen; session stay alive! There is somethng but i don't
> understand what keep alive the session...

- just in case: do you restart sshd after modifying its setup?
- As Greg Wooledge as stated, use of these sshd parameters is to permit
closing of unresponsive or hung connections, not ordinary and
responsive connections
- if you want to restrict the time of ssh connection and are in
position to modify the ssh command they use (an alias in their bashrc
for example?), perhaps you can try to force the ssh -o option with the
ConnectTimeout parameter (see ssh manpage). I have never done it
myself, so I don't know if it can solve your problem.

Re: SSH timeout logoff don't work!

[Nicholas Geovanis]

On Tue, Jun 21, 2022 at 6:04 AM Greg Wooledge  wrote:

> On Tue, Jun 21, 2022 at 10:05:43AM +0200, Conti Stefano wrote:
> > Hello! In My Debian 11 SSH timeout logoff not work! I must put in
> > .bashrc of my user: TMOUT=600 to loogut after 10 minutes. Work, of
> > course, but close all bash terminal!
> >
> > This is my sshd_config with info for timeout:
> >
> > TCPKeepAlive no
> > ClientAliveInterval 600
> > ClientAliveCountMax 0
>
> Those settings *are not* supposed to close an idle ssh session.  Nothing
> in ssh is supposed to close an idle session.  There isn't any facility
> to do that, because it's entirely contrary to the design of ssh.
>
> Your TMOUT solution is the standard way to appease the managerial morons
> who are asking this of you.


Well, it's one of the standard ways. The other is to let the network admins
do it instead.


> It asks the shell to terminate if it's
> sitting idle for however many seconds you specify.  If the shell closes,
> then the ssh session is free to close as well, assuming there are no
> active tunneling connections, etc.
>
>

Re: SSH timeout logoff don't work!

[Greg Wooledge]

On Tue, Jun 21, 2022 at 02:02:38PM +0200, Conti Stefano wrote:
> Excuse me but i sure you that i use this practice from many years and
> always work in the past. I've a other distro, an "old" Debian 9 and a
> Centos 7 with SSH version 7.4p1 and i'm sure work all well because i
> put  ClientAliveInterval 15 and after 15 seconds SSH session closed!

sshd_config(5) says:

 ClientAliveInterval
 Sets a timeout interval in seconds after which if no data has
 been received from the client, sshd(8) will send a message
 through the encrypted channel to request a response from the
 client.  The default is 0, indicating that these messages will
 not be sent to the client.

Nothing here relates to *idle* sessions.  If you scroll up to the previous
section:

 ClientAliveCountMax
 Sets the number of client alive messages which may be sent with‐
 out sshd(8) receiving any messages back from the client. [...]

 The default value is 3.  If ClientAliveInterval is set to 15, and
 ClientAliveCountMax is left at the default, unresponsive SSH
 clients will be disconnected after approximately 45 seconds.
 Setting a zero ClientAliveCountMax disables connection termina‐
 tion.

This still doesn't relate to idle sessions.  It's there to remove
*non-responsive* sessions -- ones where the client has crashed, or
where the network connection between the client and server has stopped
transmitting packets.

Re: SSH timeout logoff don't work!

[Greg Wooledge]

On Tue, Jun 21, 2022 at 10:05:43AM +0200, Conti Stefano wrote:
> Hello! In My Debian 11 SSH timeout logoff not work! I must put in
> .bashrc of my user: TMOUT=600 to loogut after 10 minutes. Work, of
> course, but close all bash terminal!
> 
> This is my sshd_config with info for timeout: 
> 
> TCPKeepAlive no
> ClientAliveInterval 600
> ClientAliveCountMax 0

Those settings *are not* supposed to close an idle ssh session.  Nothing
in ssh is supposed to close an idle session.  There isn't any facility
to do that, because it's entirely contrary to the design of ssh.

Your TMOUT solution is the standard way to appease the managerial morons
who are asking this of you.  It asks the shell to terminate if it's
sitting idle for however many seconds you specify.  If the shell closes,
then the ssh session is free to close as well, assuming there are no
active tunneling connections, etc.

Re: SSH timeout logoff don't work!

[didier gaumet]

Le mardi 21 juin 2022 à 10:05 +0200, Conti Stefano a écrit :
> Hello! In My Debian 11 SSH timeout logoff not work! I must put in
> .bashrc of my user: TMOUT=600 to loogut after 10 minutes. Work, of
> course, but close all bash terminal!
> 
> This is my sshd_config with info for timeout: 
> 
> TCPKeepAlive no
> ClientAliveInterval 600
> ClientAliveCountMax 0
>  
> Any suggest?

Disclaimer: I am not knowledgeable in ssh/sshd matters

If I am not wrong, from what I understand from sshd_config manpage:
https://manpages.debian.org/bullseye/openssh-server/sshd_config.5.en.html
this behavior is what it is supposed to be: 
DisconnectionDelay=ClientAliveInterval*ClientAliveCountMax
(times expressed in seconds)

ClientAliveCountMax set to 0 disables disconnection and is set by
default to 3.

For example, to have a 10mn disconnection delay, you could set:
- ClientAliveCountMax to 3 (default) and ClientAliveInterval to 200
- ClientAliveCountMax to 1 and ClientAliveInterval to 600
- ClientAliveCountMax to 10 and ClientAliveInterval to 60
...

Re: ssh-agent: I want to start using on all my remote hosts

[Tom Browder]

On Sat, Jun 4, 2022 at 13:52 john doe  wrote:

> On 6/4/2022 8:28 PM, Tom Browder wrote:
> > On Sat, Jun 4, 2022 at 10:02 Andy Smith  wrote:
> > ...
> >
> > You seem to be very reboot-happy. I recommend understanding the
> >> impact of the changes you will make instead of assuming you need to
> >> reboot to make them effective.
> >
> >
> > Andy. I know I'm "reboot happy," but it's lazyness (no other users at the
> > moment) and fading memory for little-used details.
> >
>
> At the very least, you should document what you do! :)


Actually I do and have my current ssh set up documented. And it includes
note on how to restart the ssh service. (I'm not even sure if ssh-agent was
around with the original ssh.)

If I recall correctly, you are setting up a server for production use,
> rebooting might not be an option  when this server is put in production.


As I said, I'm still the only user, and the droplet I'm experimenting with
boots up quickly at the moment (and it's not in production yet). So
lazyness reigns for now  ;-D

-Tom

Re: ssh-agent: I want to start using on all my remote hosts

[john doe]

On 6/4/2022 8:28 PM, Tom Browder wrote:

On Sat, Jun 4, 2022 at 10:02 Andy Smith  wrote:
...

You seem to be very reboot-happy. I recommend understanding the

impact of the changes you will make instead of assuming you need to
reboot to make them effective.



Andy. I know I'm "reboot happy," but it's lazyness (no other users at the
moment) and fading memory for little-used details.



At the very least, you should document what you do! :)

If I recall correctly, you are setting up a server for production use,
rebooting might not be an option  when this server is put in production.

--
John Doe

Re: ssh-agent: I want to start using on all my remote hosts

[Tom Browder]

On Sat, Jun 4, 2022 at 10:02 Andy Smith  wrote:
...

You seem to be very reboot-happy. I recommend understanding the
> impact of the changes you will make instead of assuming you need to
> reboot to make them effective.


Andy. I know I'm "reboot happy," but it's lazyness (no other users at the
moment) and fading memory for little-used details.

But I do appreciate your help.

-Tom

Re: ssh-agent: I want to start using on all my remote hosts

[Andy Smith]

Hello,

On Fri, Jun 03, 2022 at 09:43:53AM -0500, Tom Browder wrote:
> 1. Will starting the ssh-agent service interfere with my current ssh login
> (using keys with NO passhrase).

It only matters at the point of authentication, so existing SSH
sessions will not be affected.

> 2. Is there anything to do to start the service other than:
> 
> edit file /etc/ssh/sshd_config to uncomment
> 
> #AllowAgentForwarding yes

The directive you are proposing to uncomment defaults to "yes", so
you need not make any change.

> reboot

You seem to be very reboot-happy. I recommend understanding the
impact of the changes you will make instead of assuming you need to
reboot to make them effective.

In this case you do not need to make a change to your sshd's config,
but if you *did*, it would only be affecting sshd not anything else
on the system. So you'd only need to restart sshd.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Re: ssh-agent: I want to start using on all my remote hosts

[Andy Smith]

Hello,

On Fri, Jun 03, 2022 at 09:52:26AM -0500, Tom Browder wrote:
> And edit file /etc/ssh/ssh_config to change
> 
> # ForwardAgent no
> 
> to
> 
> ForwardAgent yes
> 
> Then reboot.

This is a config file for the ssh client, i.e. the "ssh" command.
As such it's read every time you run ssh and you do not need to
reboot the system after changing its configuration.

Also, the file you mention is the system-wide configuration file,
but the change can also be made on a per-user basis by editing
~/.ssh/config.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Re: How about ssh certificates (was: Re: ssh-agent: I want to start using on all my remote hosts)

[rhkramer]

Ahh, thanks Greg, I can now see those missing parts of the article -- it was 
NoScript, but, seeing most of the graphics in the article, somehow NoScript 
didn't come to mind as the cause of the problem.



On Friday, June 03, 2022 02:29:45 PM Greg Wooledge wrote:
> On Fri, Jun 03, 2022 at 01:16:45PM -0500, Tom Browder wrote:
> This happens ALL THE TIME when I use NoScript.
> 
> > I briefly looked at the article and didn't notice anything missing. Maybe
> > if you could take some screen shots in those areas we could help.
> 
> The first one I found is after this sentence:
> 
>   Copy it to a file on CA server and run the command:
> 
> NoScript initially reports 3 domains:
> 
>   betterprogramming.pub
>   cloudflareinsights.com
>   medium.com
> 
> Telling NoScript to Temp.Trust all 3 of these domains fixes this one
> (for me).  And once I do that, NoScript now reports that there are 7
> domains.  One of them (github.com) is already trusted, so you might need
> that one as well -- I don't know.
> 
> I'm sure you're used to this, if you're a NoScript user.

Re: How about ssh certificates (was: Re: ssh-agent: I want to start using on all my remote hosts)

[Tom Browder]

On Fri, Jun 3, 2022 at 13:46  wrote:

> On Friday, June 03, 2022 02:16:45 PM Tom Browder wrote:
> > I briefly looked at the article and didn't notice anything missing. Maybe
> > if you could take some screen shots in those areas we could help.
>
> Thanks for the reply, and thanks, I'll do that.
>
> I guess you intentionally replied off list, but that means I can attach
> some
> screen shots without worrying about whether that violates a list policy.


Hm, no I don't see that I replied off list, maybe you're having a browser
problem of some kind as you hinted.

-Tom

Re: How about ssh certificates (was: Re: ssh-agent: I want to start using on all my remote hosts)

[David Christensen]

On 6/3/22 08:46, rhkra...@gmail.com wrote:

On Friday, June 03, 2022 10:43:53 AM Tom Browder wrote:

I have been using ssh for logging in to my remote hosts for many years, but
I have NOT been using ssh-agent.


I'm intentionally not addressing your specific questions.

For me, your post is rather timely, because I'm digging into ssh and was
trying to understand the different methods of authentication and trying to
decide what was best for me.  (I have a SOHO with up to 5 nodes at time (right
now only 3.)

 From some of my reading, ssh certificates seem to be highly recommended,
although it has seemed difficult for me to get all the details I want.

The best resource I've found so far is:

https://betterprogramming.pub/how-to-use-ssh-certificates-for-scalable-secure-
and-more-transparent-server-access-720a87af6617?gi=8a3ac1f658bc

One problem with that article is that it seems that there are about 3 blanks
in it where, for example, the text mentions something like ~"use this command"
and then there is a big blank spot.  (I've tried viewing the page in 2 to 4
different browsers, depending on how you count them -- some older versions of
firefox, a fairly recent version of firefox, and an older version of konqueror).

I've looked for a way to contact the author but haven't found anything so far.

Some of the advantages of certificates are (iiuc):

* maybe a simpler setup, after you understand how to do it

* easier to manage the keys / authentication (specifically, if you need to
revoke permissions for a user you can do it in one place

* apparently the security can be somewhat better (maybe a result of the
previous bullet, but I think some other things as well)

* you can make the transition gradually -- you can keep the "old" public
key authentication in place (and continue to use it when, where, and if
needed) while you transition some server(s) and user(s) to certificates.

I thought I'd call your attention to this for your consideration -- perhaps
with both of us investigating and asking questions as needed, we both might
make quicker progress.

In any event, have a good day!



"Public key infrastructure" is large and complex; I am still climbing a 
subset of its many learning curves.



I own and recommend "TLS Mastery" by Michael W. Lucas:

https://mwl.io/nonfiction/networking#tls


David

Re: How about ssh certificates (was: Re: ssh-agent: I want to start using on all my remote hosts)

[Greg Wooledge]

On Fri, Jun 03, 2022 at 01:16:45PM -0500, Tom Browder wrote:
> On Fri, Jun 3, 2022 at 10:46  wrote:
> > 
> >
> > One problem with that article is that it seems that there are about 3
> > blanks
> > in it where, for example, the text mentions something like ~"use this
> > command"
> > and then there is a big blank spot.

This happens ALL THE TIME when I use NoScript.

> I briefly looked at the article and didn't notice anything missing. Maybe
> if you could take some screen shots in those areas we could help.

The first one I found is after this sentence:

  Copy it to a file on CA server and run the command:

NoScript initially reports 3 domains:

  betterprogramming.pub
  cloudflareinsights.com
  medium.com

Telling NoScript to Temp.Trust all 3 of these domains fixes this one
(for me).  And once I do that, NoScript now reports that there are 7
domains.  One of them (github.com) is already trusted, so you might need
that one as well -- I don't know.

I'm sure you're used to this, if you're a NoScript user.

Re: ssh-agent: I want to start using on all my remote hosts

[David Christensen]

On 6/3/22 07:43, Tom Browder wrote:

I have been using ssh for logging in to my remote hosts for many years, but
I have NOT been using ssh-agent.

I have checked all those hosts looking for the env var SSH_AGENT_SOCK which
one website says should be defined if the ssh-agent process is running, but
none have that defined.

Now I'm ready to start but I want to start with one host to make sure my
work flows aren't interrupted. Some questions:

1. Will starting the ssh-agent service interfere with my current ssh login
(using keys with NO passhrase).



Entering passphrases every time you issue an SSH-enabled command is a 
PITA.  I also used keys without passwords before I discovered 
ssh-agent(1) and ssh-add(1).  Now all of my keys have passphrases.  You 
should create new SSH keys with strong passphrases.




2. Is there anything to do to start the service other than:


On 6/3/22 07:52, Tom Browder wrote:
> On Fri, Jun 3, 2022 at 09:43 Tom Browder  wrote:

> And edit file /etc/ssh/ssh_config to change
>
>  # ForwardAgent no
>
> to
>
>  ForwardAgent yes
>
> Then reboot.


If you change /etc/ssh/ssh_config, there is no need to reboot.  I enable 
ForwardAgent on all of my hosts, so that I can login via ssh(1) and use 
cvs(1) over SSH.



If you change /etc/ssh/sshd_config, then you need to send a HUP signal 
to sshd(8), restart sshd(8), or reboot.



If you want to use your SSH key to login to root accounts, verify 
PermitRootLogin is set to (or defaults to) "prohibit-password" in 
/etc/ssh/sshd_config on the target hosts.



If you want all ssh(1) logins to require an SSH key, set 
PasswordAuthentication to "no" in /etc/ssh/sshd_config on the target hosts.



I own and recommend "SSH Mastery" by Michael W. Lucas:

https://mwl.io/nonfiction/tools#ssh


David

Re: How about ssh certificates (was: Re: ssh-agent: I want to start using on all my remote hosts)

[Tom Browder]

On Fri, Jun 3, 2022 at 10:46  wrote:

> On Friday, June 03, 2022 10:43:53 AM Tom Browder wrote:
> > I have been using ssh for logging in to my remote hosts for many years,
> but
> > I have NOT been using ssh-agent.
>
> I'm intentionally not addressing your specific questions.
>
> For me, your post is rather timely, because I'm digging into ssh and was
> trying to understand the different methods of authentication and trying to
> decide what was best for me.  (I have a SOHO with up to 5 nodes at time
> (right
> now only 3.)
>
> From some of my reading, ssh certificates seem to be highly recommended,
> although it has seemed difficult for me to get all the details I want.
>
> The best resource I've found so far is:


I remember seeing that in the past. Note when I started my
https://usafa-1965.org website in 2010 I plunged into creating ssl
certificates for my classmates to log in painlessly. But it was a pain for
me, although I built my CA with a hand-coded Perl set of programs which
helped immensely. There are now better CA solutions (open source ones,
too), but for my purposes I think the ssh-agent will be easier.

https://betterprogramming.pub/how-to-use-ssh-certificates-for-scalable-secure-
> and-more-transparent-server-access-720a87af6617?gi=8a3ac1f658bc
> 
>
> One problem with that article is that it seems that there are about 3
> blanks
> in it where, for example, the text mentions something like ~"use this
> command"
> and then there is a big blank spot.  (I've tried viewing the page in 2 to
> 4
> different browsers, depending on how you count them -- some older versions
> of
> firefox, a fairly recent version of firefox, and an older version of
> konqueror).


I briefly looked at the article and didn't notice anything missing. Maybe
if you could take some screen shots in those areas we could help.

-Tom

How about ssh certificates (was: Re: ssh-agent: I want to start using on all my remote hosts)

[rhkramer]

On Friday, June 03, 2022 10:43:53 AM Tom Browder wrote:
> I have been using ssh for logging in to my remote hosts for many years, but
> I have NOT been using ssh-agent.

I'm intentionally not addressing your specific questions.

For me, your post is rather timely, because I'm digging into ssh and was 
trying to understand the different methods of authentication and trying to 
decide what was best for me.  (I have a SOHO with up to 5 nodes at time (right 
now only 3.)

From some of my reading, ssh certificates seem to be highly recommended, 
although it has seemed difficult for me to get all the details I want.

The best resource I've found so far is:

https://betterprogramming.pub/how-to-use-ssh-certificates-for-scalable-secure-
and-more-transparent-server-access-720a87af6617?gi=8a3ac1f658bc

One problem with that article is that it seems that there are about 3 blanks 
in it where, for example, the text mentions something like ~"use this command" 
and then there is a big blank spot.  (I've tried viewing the page in 2 to 4 
different browsers, depending on how you count them -- some older versions of 
firefox, a fairly recent version of firefox, and an older version of konqueror).

I've looked for a way to contact the author but haven't found anything so far.

Some of the advantages of certificates are (iiuc):

   * maybe a simpler setup, after you understand how to do it

   * easier to manage the keys / authentication (specifically, if you need to 
revoke permissions for a user you can do it in one place

   * apparently the security can be somewhat better (maybe a result of the 
previous bullet, but I think some other things as well)

   * you can make the transition gradually -- you can keep the "old" public 
key authentication in place (and continue to use it when, where, and if 
needed) while you transition some server(s) and user(s) to certificates.

I thought I'd call your attention to this for your consideration -- perhaps 
with both of us investigating and asking questions as needed, we both might 
make quicker progress.

In any event, have a good day!

Re: ssh-agent: I want to start using on all my remote hosts

[Tom Browder]

On Fri, Jun 3, 2022 at 09:43 Tom Browder  wrote:

> I have been using ssh for logging in to my remote hosts for many years,
> but I have NOT been using ssh-agent.
>
...

And edit file /etc/ssh/ssh_config to change

# ForwardAgent no

to

ForwardAgent yes

Then reboot.

-Tom

Re : Re: SSH PasswordAuthentication à no

[benoit]

Ben oui, il y a plein de doc en plus :
https://duckduckgo.com/?q=SSH+key++authentication+with+LDAP=ffab=web

Avec gratitude,

--
Benoit




Envoyé avec la messagerie sécurisée ProtonMail.
--- Original Message ---
Le lundi 11 avril 2022 à 16:57, Roberto C. Sánchez  a écrit 
:


> On Mon, Apr 11, 2022 at 01:16:41PM +, benoit wrote:
>
> > Bonjour à tous,
> > Si sur le serveur SSH on a désactivé l’authentification par mot de passe,
> > comment fait-on pour ajouter les clés de nouveaux utilisateurs ?
> > Une fois qu'on à configuré ssh avec
> > PasswordAuthentication no
> > On ne sait plus ajouter de nouveaux utilisateur avec
> > ssh-keygen
> > ssh-copy-id toto@nom-machine
> > On doit à chaque nouvel ajout de clé, supprimer
> > PasswordAuthentication no
> > redémarrer le serveur,
> > Ajouter la clé via un nouveau client, ajouter la ligne
> > PasswordAuthentication no
> > Redémarrer ssh ?
> > Il y a-il une procédure plus simple ?
> > Merci d'avance.
>
>
> Dans ce cas, il faut donner aux utilisateurs une autre manière d'ajouter
> les clés. Par exemple, GitHub a une interface web et l'utilisateur peut
> faire un copier-coller de sa clé pour pouvoir acceder au service sans
> mot de passe pour les operations CLI git. LDAP peut aussi servir de
> manière d'utilisateurs garder ses clés. Le service ssh peut être
> configuré pour obtenir des clés de LDAP.
>
> Salut,
>
> -Roberto
> --
> Roberto C. Sánchez

Re: SSH PasswordAuthentication à no

[Roberto C . Sánchez]

On Mon, Apr 11, 2022 at 01:16:41PM +, benoit wrote:
>Bonjour à tous,
>Si sur le serveur SSH on a désactivé l’authentification par mot de passe,
>comment fait-on pour ajouter les clés de nouveaux utilisateurs ?
>Une fois qu'on à configuré ssh avec
>PasswordAuthentication no
>On ne sait plus ajouter de nouveaux utilisateur avec
>ssh-keygen
>ssh-copy-id toto@nom-machine
>On doit à chaque nouvel ajout de clé, supprimer
>PasswordAuthentication no
>redémarrer le serveur,
>Ajouter la clé via un nouveau client, ajouter la ligne
>PasswordAuthentication no
>Redémarrer ssh ?
>Il y a-il une procédure plus simple ?
>Merci d'avance.

Dans ce cas, il faut donner aux utilisateurs une autre manière d'ajouter
les clés.  Par exemple, GitHub a une interface web et l'utilisateur peut
faire un copier-coller de sa clé pour pouvoir acceder au service sans
mot de passe pour les operations CLI git.  LDAP peut aussi servir de
manière d'utilisateurs garder ses clés.  Le service ssh peut être
configuré pour obtenir des clés de LDAP.

Salut,

-Roberto
-- 
Roberto C. Sánchez

Re: ssh -X and size of GUI elements (KDE/Qt)

[Dan Ritter]

Christian Britz wrote: 
> On 2022-02-15 17:26 UTC+0100, Dan Ritter wrote:
> > It's probably a disagreement on screen dpi settings. Check your
> > native setting and then replicate it on your headless server's
> > KDE config?
> 
> Wouldn't this mainly/exclusively affect the fonts?
> I set dpi in both systemsettings5 tool explicitly to 96, without effect.
> (I could notice that values like 120 actually result in bigger fonts,
> but nothing else.)
> 
> Anyhow, purged (almost) all KDE and Qt stuff already. :-)

DPI affects anything that is drawn as scaled, rather than
bitmapped. Fonts are the most obvious effect, but most buttons
and many other interface elements are scaled.

-dsr-

Re: ssh -X and size of GUI elements (KDE/Qt)

[Christian Britz]

On 2022-02-15 17:26 UTC+0100, Dan Ritter wrote:
> It's probably a disagreement on screen dpi settings. Check your
> native setting and then replicate it on your headless server's
> KDE config?

Wouldn't this mainly/exclusively affect the fonts?
I set dpi in both systemsettings5 tool explicitly to 96, without effect.
(I could notice that values like 120 actually result in bigger fonts,
but nothing else.)

Anyhow, purged (almost) all KDE and Qt stuff already. :-)

Re: ssh -X and size of GUI elements (KDE/Qt)

[Dan Ritter]

Christian Britz wrote: 
> Hi,
> 
> when I logon to my headless server via ssh -X, I can start graphical
> applications and they are displayed on my local X server.
> 
> The font size is excactly the same as on my dektop, but GUI elements
> like buttons are somehow smaller in vertical size. It seems to depend on
> the used toolkit, I noticed it only for KDE/QT apps. Any idea?

It's probably a disagreement on screen dpi settings. Check your
native setting and then replicate it on your headless server's
KDE config?

-dsr-

Re: SSH tunnel valt weg

[Paul van der Vlis]

Op 19-12-2021 om 11:07 schreef Geert Stappers:

On Sun, Dec 19, 2021 at 12:26:29AM +0100, Paul van der Vlis wrote:

Hallo,

Ik gebruik vaak SSH tunnels en sinds een paar dagen (nog voor de point
release) vallen die tunnels na enige tijd weg. De belangrijke foutmelding is
volgens mij deze (aan de server kant):

ssh_dispatch_run_fatal: Connection from 45.95.238.187 port 56446: message
authentication code incorrect

Onderaan heb ik nog wat meer log geplakt, maar volgens mij is dat niet zo
interessant en is dit de belangrijke melding.

De logs aan de client kant heb ik helemaal onderaan geplakt, maar ik kan er
niet veel mee. Wat me opvalt is dat hij een pakket "type 1" stuurt, en
daarna valt de verbinding weg (de sessie was al even open):
debug3: send packet: type 1

Iemand een idee waarom die verbindingen wegvallen?



Verbindingen kunnen wegvallen, herstel gewoon de verbinding.

Doe je voordeel met `autossh`.


|$ apt show autossh 2> /dev/null | sed --silent -e '/^Description/,$p'
|Description: Automatically restart SSH sessions and tunnels
| autossh is a program to start an instance of ssh and monitor it, restarting it
| as necessary should it die or stop passing traffic. The idea is from rstunnel
| (Reliable SSH Tunnel), but implemented in C. Connection monitoring is done
| using a loop of port forwardings. It backs off on the rate of connection
| attempts when experiencing rapid failures such as connection refused.


Een interessante applicatie!

Toch denk ik dat er ook iets mis is wat gerepareerd kan worden. Eerder 
had ik dit probleem namelijk niet.


Groet,
Paul


--
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/

Re: SSH tunnel valt weg

[Geert Stappers]

On Sun, Dec 19, 2021 at 12:26:29AM +0100, Paul van der Vlis wrote:
> Hallo,
> 
> Ik gebruik vaak SSH tunnels en sinds een paar dagen (nog voor de point
> release) vallen die tunnels na enige tijd weg. De belangrijke foutmelding is
> volgens mij deze (aan de server kant):
> 
> ssh_dispatch_run_fatal: Connection from 45.95.238.187 port 56446: message
> authentication code incorrect
> 
> Onderaan heb ik nog wat meer log geplakt, maar volgens mij is dat niet zo
> interessant en is dit de belangrijke melding.
> 
> De logs aan de client kant heb ik helemaal onderaan geplakt, maar ik kan er
> niet veel mee. Wat me opvalt is dat hij een pakket "type 1" stuurt, en
> daarna valt de verbinding weg (de sessie was al even open):
> debug3: send packet: type 1
> 
> Iemand een idee waarom die verbindingen wegvallen?
> 

Verbindingen kunnen wegvallen, herstel gewoon de verbinding.

Doe je voordeel met `autossh`.


|$ apt show autossh 2> /dev/null | sed --silent -e '/^Description/,$p'
|Description: Automatically restart SSH sessions and tunnels
| autossh is a program to start an instance of ssh and monitor it, restarting it
| as necessary should it die or stop passing traffic. The idea is from rstunnel
| (Reliable SSH Tunnel), but implemented in C. Connection monitoring is done
| using a loop of port forwardings. It backs off on the rate of connection
| attempts when experiencing rapid failures such as connection refused.


Groeten
Geert Stappers
-- 
Silence is hard to parse

Re: (ssh-1 ongefixst maar probleem anders opgelost) Re: Debian 11, openssh server, ssh-1 toegang voor 1 client, hoe?

[Richard Lucassen]

On Thu, 18 Nov 2021 15:33:46 +0100
Gijs Hillenius  wrote:

> Wellicht wijst iemand me binnenkort terecht terecht dat ik niet moet
> peuteren aan de veiligheidsknoppen van SSH.
> 
> Ik heb mijn onderliggende probleem (met een legacy Android app)
> inmiddels op een andere manier opgelost.

Het blijft ook een eeuwig probleem. Net zoals browsers die niet meer
willen connecten met bijv een oudere versie ILO van een HP server. Oude
spullen gebruiken, al dan niet in een VM is dan de oplossing. Voor
Debian is er het pakket openssh-client-ssh1 (dat is dan voor jou wel in
de andere richting):

secure shell (SSH) client for legacy SSH1 protocol

Nadeeltje is wel dat-ie out of the box de "normale" ssh_config
gebruikt en daardoor gaat zeuren, je zult dus een ssh1_config moeten
aanmaken en die specifiek moeten gebruiken.

Maar kun je sshd in de configs niet zo maken dat-ie toch die oude
ciphers accepteert?

Er is zo te zien geen pakket openssh-server-ssh1 die je op een andere
poort kan laten draaien met een firewall ervoor.

-- 
richard lucassen
http://contact.xaq.nl/