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

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

Re: ssh

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: ssh David Christensen <dpchrist@holgerdanske.com> - 2018-11-13 04:30 +0100
    Re: ssh Alan Taylor <ataylor@ieee.org> - 2018-11-13 05:40 +0100
      Re: ssh David Christensen <dpchrist@holgerdanske.com> - 2018-11-13 08:40 +0100
        Re: ssh Alan Taylor <alan.james.taylor@gmail.com> - 2018-11-15 07:20 +0100
          Re: ssh David Christensen <dpchrist@holgerdanske.com> - 2018-11-15 18:30 +0100
            Re: ssh Alan Taylor <alan.james.taylor@gmail.com> - 2018-11-17 05:30 +0100
              Re: ssh Michael Howard <mike@dewberryfields.co.uk> - 2018-11-18 13:00 +0100
                Re: ssh Alan Taylor <alan.james.taylor@gmail.com> - 2018-11-19 03:50 +0100
                  Re: ssh Michael Howard <mike@dewberryfields.co.uk> - 2018-11-19 08:40 +0100
                    Re: ssh john doe <johndoe65534@mail.com> - 2018-11-19 09:50 +0100
                    Re: ssh Michael Stone <mstone@debian.org> - 2018-11-19 14:40 +0100
                      Re: ssh Jim Popovitch <jim@k4vqc.com> - 2018-11-19 15:50 +0100
                        Re: ssh Michael Stone <mstone@debian.org> - 2018-11-19 18:20 +0100
                          Re: ssh Jim Popovitch <jim@k4vqc.com> - 2018-11-19 19:10 +0100
                          Re: ssh Michael Stone <mstone@debian.org> - 2018-11-20 03:20 +0100
                    Re: ssh Greg Wooledge <wooledg@eeg.ccf.org> - 2018-11-19 14:40 +0100

#202349 — Re: ssh

On 11/12/18 5:49 AM, Alan Taylor wrote:
> Greetings,

Hi.  :-)


> I have an ssh problem - one user can use it successfully, another cannot. I have checked and rechecked permissions until I am blue in the face …
> At the moment just trying to ssh into the same machine I am on for the problem user (the other user can ssh successfully, both to the console machine and outwards to others).
> Agent problem ? The successful user was setup in the installation, the problem user was added at the command line after initial setup.

Trouble-shooting can be tedious...


> Log output follows, appears to fail after the preauth stage …
> 
> Any suggestions gratefully accepted
> 
> root@sirius/etc/ssh # journalctl | grep sshd | grep "Nov 12 13:45"
<snip>


I would enter the following commands into the indicated accounts and 
computers, substituting place holders with actual values (USERNAME, 
SSH_CLIENT, SSH_SERVER).  If you still don't see it, cut and paste your 
console sessions into a reply:

1.  As the user having problems on the computer having problems:

	$ whoami

	$ hostname

	$ cat /etc/debian_version

	$ uname -a

	$ dpkg-query -W openssh-client

	$ ls -aFl /home/USERNAME/.ssh

	$ ssh -v SSH_SERVER

2.  As root on the SSH server:

	# hostname

	# cat /etc/debian_version

	# uname -a

	# dpkg-query -W openssh-server

	# ls -aFl /home/USERNAME/.ssh

	# grep USERNAME@SSH_CLIENT /home/USERNAME/.ssh/authorized_keys

	# tail /var/log/auth.log


David

[toc] | [next] | [standalone]

#202350

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

Hello,

Output from several suggestions:
------------------------------------------------
Permissions (backuppc is the user having problems) :

backuppc@sirius:~$ ls -ld /usr/local/BackupPC
drwxr-xr-x 6 backuppc backuppc 4096 Nov 13 12:12 /usr/local/BackupPC
backuppc@sirius:~$ ls -ld /usr/local/BackupPC/.ssh
drwx------ 2 backuppc backuppc 4096 Nov 13 12:08 /usr/local/BackupPC/.ssh
backuppc@sirius:~$ ls -l /usr/local/BackupPC/.sshtotal 28
-rw------- 1 backuppc backuppc 1790 Nov 13 12:04 authorized_keys
-rw-r----- 1 backuppc backuppc 2240 Nov 13 12:02 config
-rw-r--r-- 1 backuppc backuppc  142 Nov 13 12:08 known_hosts
-rw------- 1 backuppc backuppc  484 Nov 13 12:03 sirius_bpc-id_ed25519
-rw-r----- 1 backuppc backuppc  126 Nov 13 12:03 sirius_bpc-id_ed25519.pub
-rw------- 1 backuppc backuppc 3479 Nov 13 12:04 sirius_bpc-id_rsa
-rw-r----- 1 backuppc backuppc  770 Nov 13 12:04 sirius_bpc-id_rsa.pub
backuppc@sirius:~$
backuppc@sirius:~$ ls -la /etc/ssh
drwxr-xr-x   2 root root   4096 Nov 13 12:04 .
drwxr-xr-x 131 root root  12288 Nov 13 12:05 ..
-rw-r--r--   1 root root 511915 Nov 13 12:02 moduli
-rw-r--r--   1 root root 553122 Aug 21 11:14 moduli.dist
-rw-------   1 root root    888 Nov 13 12:03 sirius_alan-authorized_keys
-rw-rw----   1 root root    896 Nov 13 12:04 sirius_bpc-authorized_keys
-rw-r--r--   1 root root   2830 Nov 13 12:02 ssh_config
-rw-r--r--   1 root root   1723 Aug 21 11:14 ssh_config.dist
-rw-r--r--   1 root root   4239 Nov 13 12:02 sshd_config
-rw-r--r--   1 root root   3298 Aug 21 11:14 sshd_config.dist
-rw-------   1 root root    432 Nov 13 12:03 ssh_host_ed25519_key
-rw-r-----   1 root root    117 Nov 13 12:03 ssh_host_ed25519_key.pub
-rw-------   1 root root   3243 Nov 13 12:03 ssh_host_rsa_key
-rw-r-----   1 root root    761 Nov 13 12:03 ssh_host_rsa_key.pub
backuppc@sirius:~$
These permissions are identical to the user that works.
------------------------------------------------
Output from David's troubleshooting :

As backuppc (problem user):

backuppc@sirius:~$ whoami
backuppc
backuppc@sirius:~$ hostname
sirius
backuppc@sirius:~$ cat /etc/debian_version
9.6
backuppc@sirius:~$ uname -a
Linux sirius 4.9.0-8-amd64 #1 SMP Debian 4.9.130-2 (2018-10-27) x86_64
GNU/Linux
backuppc@sirius:~$ dpkg-query -W openssh-client
openssh-client    1:7.4p1-10+deb9u4

backuppc@sirius:~$ ls -aFl /usr/local/BackupPC/.ssh
total 36
drwx------ 2 backuppc backuppc 4096 Nov 13 12:08 ./
drwxr-xr-x 6 backuppc backuppc 4096 Nov 13 12:12 ../
-rw------- 1 backuppc backuppc 1790 Nov 13 12:04 authorized_keys
-rw-r----- 1 backuppc backuppc 2240 Nov 13 12:02 config
-rw-r--r-- 1 backuppc backuppc  142 Nov 13 12:08 known_hosts
-rw------- 1 backuppc backuppc  484 Nov 13 12:03 sirius_bpc-id_ed25519
-rw-r----- 1 backuppc backuppc  126 Nov 13 12:03 sirius_bpc-id_ed25519.pub
-rw------- 1 backuppc backuppc 3479 Nov 13 12:04 sirius_bpc-id_rsa
-rw-r----- 1 backuppc backuppc  770 Nov 13 12:04 sirius_bpc-id_rsa.pub

backuppc@sirius:~$ ssh -v sirius
OpenSSH_7.4p1 Debian-10+deb9u4, OpenSSL 1.0.2l  25 May 2017
debug1: Reading configuration data /usr/local/BackupPC/.ssh/config
debug1: /usr/local/BackupPC/.ssh/config line 16: Applying options for sirius
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: /etc/ssh/ssh_config line 69: Deprecated option "useroaming"
debug1: Connecting to 192.168.8.3 [192.168.8.3] port 50400.
debug1: Connection established.
debug1: identity file /usr/local/BackupPC/.ssh/sirius_bpc-id_ed25519 type 4
debug1: key_load_public: No such file or directory
debug1: identity file /usr/local/BackupPC/.ssh/sirius_bpc-id_ed25519-cert
type -1
debug1: identity file /usr/local/BackupPC/.ssh/sirius_bpc-id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /usr/local/BackupPC/.ssh/sirius_bpc-id_rsa-cert type
-1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.4p1 Debian-10+deb9u4
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4p1
Debian-10+deb9u4
debug1: match: OpenSSH_7.4p1 Debian-10+deb9u4 pat OpenSSH* compat 0x0400000
0
debug1: Authenticating to 192.168.8.3:50400 as 'backuppc'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256@libssh.org
debug1: kex: host key algorithm: ssh-ed25519
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC:
<implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC:
<implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ssh-ed25519
SHA256:Qmmw9Hw9F68Lv9vTJTHpbJtwOzxUxod4FFAnA16D5bk
debug1: Host '[192.168.8.3]:50400' is known and matches the ED25519 host
key.
debug1: Found key in /usr/local/BackupPC/.ssh/known_hosts:1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info:
server-sig-algs=<ssh-ed25519,ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering ED25519 public key:
/usr/local/BackupPC/.ssh/sirius_bpc-id_ed25519
debug1: Server accepts key: pkalg ssh-ed25519 blen 51
debug1: Offering RSA public key: /usr/local/BackupPC/.ssh/sirius_bpc-id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 535
debug1: No more authentication methods to try.
Permission denied (publickey).
backuppc@sirius:~$
____________
as root :

root@sirius:~# whoami
root
root@sirius:~# hostname
sirius
root@sirius:~# cat /etc/debian_version
9.6
root@sirius:~# uname -a
Linux sirius 4.9.0-8-amd64 #1 SMP Debian 4.9.130-2 (2018-10-27) x86_64
GNU/Linux
root@sirius:~# dpkg-query -W openssh-client
openssh-client    1:7.4p1-10+deb9u4

root@sirius:~# ls -aFl /usr/local/BackupPC/.ssh
total 36
drwx------ 2 backuppc backuppc 4096 Nov 13 12:08 ./
drwxr-xr-x 6 backuppc backuppc 4096 Nov 13 12:12 ../
-rw------- 1 backuppc backuppc 1790 Nov 13 12:04 authorized_keys
-rw-r----- 1 backuppc backuppc 2240 Nov 13 12:02 config
-rw-r--r-- 1 backuppc backuppc  142 Nov 13 12:08 known_hosts
-rw------- 1 backuppc backuppc  484 Nov 13 12:03 sirius_bpc-id_ed25519
-rw-r----- 1 backuppc backuppc  126 Nov 13 12:03 sirius_bpc-id_ed25519.pub
-rw------- 1 backuppc backuppc 3479 Nov 13 12:04 sirius_bpc-id_rsa
-rw-r----- 1 backuppc backuppc  770 Nov 13 12:04 sirius_bpc-id_rsa.pub

root@sirius:~# grep backuppc@sirius
/usr/local/BackupPC/.ssh/authorized_keys
ssh-ed25519
AAAAC3NzaC1lZDI1NTE5AAAAIBIG1jFCDbjX1AuKEpi3U0rPtxW79kZwcEAzN+shbnni
Generated on 181113.1203 for backuppc@sirius
ssh-rsa
AAAAB3NzaC1yc2EAAAADAQABAAACAQD2fiZLF9Q0+RKERleUw2LnoEXF3FdF/UPPX+khWUVIc+SWG+mTSIlFeEWNeoLpa32Vfb0T8cNooMgR6sodxQZlzC15ByPSotW7AHAdBylzkP0G4GM4zTYlkfuIzeJClNrNuphzbdIa8dH9xhmhqE7FbHcq34LErQX1zBfGcDVyqUABVdXTLqtDKRS2P3hCQ8gR8u0BDesvTUYWPwJXkXaq9UdS9VWsJuyQhnqzFKOm+cPdoqRFtvVAIxlqAyI9ok7d/cve4nIjFPg1n7ralTw4x8D4oxmOpUNqOC4dJYDCbihY3nImq0oB/+zt6uS3t232qjaUGrt0pUB2AywQwULYhGhAsiqGEaoJuuYUonCXT4IHxTIBFJraVSvr53gcM7Jm9kBcLG8x2B5rtiZzBImITv+nZnqTJgBu5q+ZBqm5FK4miBHjinscXxqCLmljXOW7Ui7uhg1NjcYMdaC1BRJoHzsTkIvnoRmONdUbDCK63n9MHikiRrvdme8SUQDjuKHfS5nNMClDfMF69Rgr27QkqOMOYYA2mqvcrjxtXS1n9DA88dnhCKsHfTDXCto710CHzQPh7YuUzlL8uNAE4RwzhOCDxgaI4WV9/qj2J+0C2PE0dkTwFqBuGytyBYFglpIhmnlucukdccZ5i/YpEkITvccB7EO/sPSRzAnm55iGUw==
Generated on 181113.1203 for backuppc@sirius

root@sirius:~# tail -n 20 /var/log/auth.log
Nov 13 12:28:07 sirius sshd[2159]: debug1: fd 4 clearing O_NONBLOCK
Nov 13 12:28:07 sirius sshd[2159]: debug2: user_key_allowed: check options:
'ssh-ed25519
AAAAC3NzaC1lZDI1NTE5AAAAIBIG1jFCDbjX1AuKEpi3U0rPtxW79kZwcEAzN+shbnni
Generated on 181113.1203 for backuppc@sirius\n'
Nov 13 12:28:07 sirius sshd[2159]: debug2: user_key_allowed: advance:
'AAAAC3NzaC1lZDI1NTE5AAAAIBIG1jFCDbjX1AuKEpi3U0rPtxW79kZwcEAzN+shbnni
Generated on 181113.1203 for backuppc@sirius\n'
Nov 13 12:28:07 sirius sshd[2159]: debug1: matching key found: file
/usr/local/BackupPC/.ssh/authorized_keys, line 2 RSA
SHA256:/TFnCvwpyL6W0Z4I71jw9u3eY4rWqB9lnHVSx3mdYNM
Nov 13 12:28:07 sirius sshd[2159]: debug1: restore_uid: 0/0
Nov 13 12:28:07 sirius sshd[2159]: debug3: mm_answer_keyallowed: key
0x55f0b985d0d0 is allowed
Nov 13 12:28:07 sirius sshd[2159]: debug3: mm_request_send entering: type 23
Nov 13 12:28:07 sirius sshd[2159]: debug3: send packet: type 60 [preauth]
Nov 13 12:28:07 sirius sshd[2159]: debug2: userauth_pubkey: authenticated 0
pkalg ssh-rsa [preauth]
Nov 13 12:28:07 sirius sshd[2159]: Postponed publickey for backuppc from
192.168.8.3 port 48708 ssh2 [preauth]
Nov 13 12:28:07 sirius sshd[2159]: Connection closed by 192.168.8.3 port
48708 [preauth]
Nov 13 12:28:07 sirius sshd[2159]: debug1: do_cleanup [preauth]
Nov 13 12:28:07 sirius sshd[2159]: debug3: PAM: sshpam_thread_cleanup
entering [preauth]
Nov 13 12:28:07 sirius sshd[2159]: debug1: monitor_read_log: child log fd
closed
Nov 13 12:28:07 sirius sshd[2159]: debug3: mm_request_receive entering
Nov 13 12:28:07 sirius sshd[2159]: debug1: do_cleanup
Nov 13 12:28:07 sirius sshd[2159]: debug1: PAM: cleanup
Nov 13 12:28:07 sirius sshd[2159]: debug3: PAM: sshpam_thread_cleanup
entering
Nov 13 12:28:07 sirius sshd[2159]: debug1: Killing privsep child 2160
Nov 13 12:28:07 sirius sshd[2159]: debug1: audit_event: unhandled event 12
root@sirius:~#

On Tue, 13 Nov 2018 at 11:22, David Christensen <dpchrist@holgerdanske.com>
wrote:

> On 11/12/18 5:49 AM, Alan Taylor wrote:
> > Greetings,
>
> Hi.  :-)
>
>
> > I have an ssh problem - one user can use it successfully, another
> cannot. I have checked and rechecked permissions until I am blue in the
> face …
> > At the moment just trying to ssh into the same machine I am on for the
> problem user (the other user can ssh successfully, both to the console
> machine and outwards to others).
> > Agent problem ? The successful user was setup in the installation, the
> problem user was added at the command line after initial setup.
>
> Trouble-shooting can be tedious...
>
>
> > Log output follows, appears to fail after the preauth stage …
> >
> > Any suggestions gratefully accepted
> >
> > root@sirius/etc/ssh # journalctl | grep sshd | grep "Nov 12 13:45"
> <snip>
>
>
> I would enter the following commands into the indicated accounts and
> computers, substituting place holders with actual values (USERNAME,
> SSH_CLIENT, SSH_SERVER).  If you still don't see it, cut and paste your
> console sessions into a reply:
>
> 1.  As the user having problems on the computer having problems:
>
>         $ whoami
>
>         $ hostname
>
>         $ cat /etc/debian_version
>
>         $ uname -a
>
>         $ dpkg-query -W openssh-client
>
>         $ ls -aFl /home/USERNAME/.ssh
>
>         $ ssh -v SSH_SERVER
>
> 2.  As root on the SSH server:
>
>         # hostname
>
>         # cat /etc/debian_version
>
>         # uname -a
>
>         # dpkg-query -W openssh-server
>
>         # ls -aFl /home/USERNAME/.ssh
>
>         # grep USERNAME@SSH_CLIENT /home/USERNAME/.ssh/authorized_keys
>
>         # tail /var/log/auth.log
>
>
> David
>
>

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

#202352

Alan:

Let's keep this on-list.  I am subscribed.


So, you have installed the Debian package 'backuppc' on host 'sirius', 
and intend to use it as a BackupPC server?


The package created the group 'backuppc' and the user 'backuppc', with 
home directory '/usr/local/BackupPC'?


How were the contents of your /etc/ssh created?  The permissions don't 
match mine -- my *_key files are 0600 and everything else is 0644.


The metadata for your /usr/local/BackupPC/.ssh looks okay.


How were the contents of your /usr/local/BackupPC/.ssh created?  The 
permissions don't match mine -- my *.pub files are 0644 and everything 
else is 0600.


My client .ssh directory has 1 hard link.  Do you know why yours has 2?


There are some lines in your login attempt that look suspicious -- I 
have noted them with asterisks (*):

     debug1: identity file 
/usr/local/BackupPC/.ssh/sirius_bpc-id_ed25519 type 4
*   debug1: key_load_public: No such file or directory


     debug1: identity file /usr/local/BackupPC/.ssh/sirius_bpc-id_rsa type 1
*   debug1: key_load_public: No such file or directory


Doing the same test on my network produces the same messages, but the 
login works correctly.  So, I think we can ignore "key_load_public: No 
such file or directory" (?).


Comparing your 'ssh -v sirius' to testing on my network, the output 
diverges after the line:

     Server accepts key: pkalg ssh-rsa blen 535

Mine then says:

     debug1: Authentication succeeded (publickey).
     Authenticated to cvs ([192.168.1.25]:22).
     debug1: channel 0: new [client-session]
     debug1: Requesting no-more-sessions@openssh.com
     debug1: Entering interactive session.
     debug1: pledge: network
     debug1: client_input_global_request: rtype hostkeys-00@openssh.com 
want_reply 0
     debug1: Sending environment.
     debug1: Sending env LANG = C


Localization and UTF-8 have caused me problems in the past, so I have 
the following line in my .profile.  This may or may not help you:

     export LANG=C


The entries in your authorized_keys file look different than mine -- 
yours contain ' Generated on 181113.1203 for' near the end of both 
matching entries.  Do your *.pub files have this phrase?  How was your 
authorized_keys created?


After a successful login, my auth.log says:

     Nov 12 22:49:36 dipsy sshd[3395]: Accepted publickey for dpchrist 
from 192.168.1.142 port 39164 ssh2: RSA 
SHA256:BAg+ZqGUnRYXU0QssQkuaBqzjxsgyjIKJeoZ8H5SG9E
     Nov 12 22:49:36 dipsy sshd[3395]: pam_unix(sshd:session): session 
opened for user dpchrist by (uid=0)


I would reset the modes of your SSH client files as backuppc@sirius:

     $ cd /usr/local/BackupPC/.ssh

     $ chmod 0600 *

     $ chmod 0644 *.pub


I would reset the modes of your SSH server files as root@sirius:

     # cd /etc/ssh

     # chmod 0644 *

     # chmod 0600 *_key


Then try 'ssh -v sirius' and look at auth.log.


David



On 11/12/18 8:34 PM, Alan Taylor wrote:
> Hello,
> 
> Output from several suggestions:
> ------------------------------------------------
> Permissions (backuppc is the user having problems) :
> 
> backuppc@sirius:~$ ls -ld /usr/local/BackupPC
> drwxr-xr-x 6 backuppc backuppc 4096 Nov 13 12:12 /usr/local/BackupPC
> backuppc@sirius:~$ ls -ld /usr/local/BackupPC/.ssh
> drwx------ 2 backuppc backuppc 4096 Nov 13 12:08 /usr/local/BackupPC/.ssh
> backuppc@sirius:~$ ls -l /usr/local/BackupPC/.sshtotal 28
> -rw------- 1 backuppc backuppc 1790 Nov 13 12:04 authorized_keys
> -rw-r----- 1 backuppc backuppc 2240 Nov 13 12:02 config
> -rw-r--r-- 1 backuppc backuppc  142 Nov 13 12:08 known_hosts
> -rw------- 1 backuppc backuppc  484 Nov 13 12:03 sirius_bpc-id_ed25519
> -rw-r----- 1 backuppc backuppc  126 Nov 13 12:03 sirius_bpc-id_ed25519.pub
> -rw------- 1 backuppc backuppc 3479 Nov 13 12:04 sirius_bpc-id_rsa
> -rw-r----- 1 backuppc backuppc  770 Nov 13 12:04 sirius_bpc-id_rsa.pub
> backuppc@sirius:~$
> backuppc@sirius:~$ ls -la /etc/ssh
> drwxr-xr-x   2 root root   4096 Nov 13 12:04 .
> drwxr-xr-x 131 root root  12288 Nov 13 12:05 ..
> -rw-r--r--   1 root root 511915 Nov 13 12:02 moduli
> -rw-r--r--   1 root root 553122 Aug 21 11:14 moduli.dist
> -rw-------   1 root root    888 Nov 13 12:03 sirius_alan-authorized_keys
> -rw-rw----   1 root root    896 Nov 13 12:04 sirius_bpc-authorized_keys
> -rw-r--r--   1 root root   2830 Nov 13 12:02 ssh_config
> -rw-r--r--   1 root root   1723 Aug 21 11:14 ssh_config.dist
> -rw-r--r--   1 root root   4239 Nov 13 12:02 sshd_config
> -rw-r--r--   1 root root   3298 Aug 21 11:14 sshd_config.dist
> -rw-------   1 root root    432 Nov 13 12:03 ssh_host_ed25519_key
> -rw-r-----   1 root root    117 Nov 13 12:03 ssh_host_ed25519_key.pub
> -rw-------   1 root root   3243 Nov 13 12:03 ssh_host_rsa_key
> -rw-r-----   1 root root    761 Nov 13 12:03 ssh_host_rsa_key.pub
> backuppc@sirius:~$
> These permissions are identical to the user that works.
> ------------------------------------------------
> Output from David's troubleshooting :
> 
> As backuppc (problem user):
> 
> backuppc@sirius:~$ whoami
> backuppc
> backuppc@sirius:~$ hostname
> sirius
> backuppc@sirius:~$ cat /etc/debian_version
> 9.6
> backuppc@sirius:~$ uname -a
> Linux sirius 4.9.0-8-amd64 #1 SMP Debian 4.9.130-2 (2018-10-27) x86_64
> GNU/Linux
> backuppc@sirius:~$ dpkg-query -W openssh-client
> openssh-client    1:7.4p1-10+deb9u4
> 
> backuppc@sirius:~$ ls -aFl /usr/local/BackupPC/.ssh
> total 36
> drwx------ 2 backuppc backuppc 4096 Nov 13 12:08 ./
> drwxr-xr-x 6 backuppc backuppc 4096 Nov 13 12:12 ../
> -rw------- 1 backuppc backuppc 1790 Nov 13 12:04 authorized_keys
> -rw-r----- 1 backuppc backuppc 2240 Nov 13 12:02 config
> -rw-r--r-- 1 backuppc backuppc  142 Nov 13 12:08 known_hosts
> -rw------- 1 backuppc backuppc  484 Nov 13 12:03 sirius_bpc-id_ed25519
> -rw-r----- 1 backuppc backuppc  126 Nov 13 12:03 sirius_bpc-id_ed25519.pub
> -rw------- 1 backuppc backuppc 3479 Nov 13 12:04 sirius_bpc-id_rsa
> -rw-r----- 1 backuppc backuppc  770 Nov 13 12:04 sirius_bpc-id_rsa.pub
> 
> backuppc@sirius:~$ ssh -v sirius
> OpenSSH_7.4p1 Debian-10+deb9u4, OpenSSL 1.0.2l  25 May 2017
> debug1: Reading configuration data /usr/local/BackupPC/.ssh/config
> debug1: /usr/local/BackupPC/.ssh/config line 16: Applying options for sirius
> debug1: Reading configuration data /etc/ssh/ssh_config
> debug1: /etc/ssh/ssh_config line 19: Applying options for *
> debug1: /etc/ssh/ssh_config line 69: Deprecated option "useroaming"
> debug1: Connecting to 192.168.8.3 [192.168.8.3] port 50400.
> debug1: Connection established.
> debug1: identity file /usr/local/BackupPC/.ssh/sirius_bpc-id_ed25519 type 4
> debug1: key_load_public: No such file or directory
> debug1: identity file /usr/local/BackupPC/.ssh/sirius_bpc-id_ed25519-cert
> type -1
> debug1: identity file /usr/local/BackupPC/.ssh/sirius_bpc-id_rsa type 1
> debug1: key_load_public: No such file or directory
> debug1: identity file /usr/local/BackupPC/.ssh/sirius_bpc-id_rsa-cert type
> -1
> debug1: Enabling compatibility mode for protocol 2.0
> debug1: Local version string SSH-2.0-OpenSSH_7.4p1 Debian-10+deb9u4
> debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4p1
> Debian-10+deb9u4
> debug1: match: OpenSSH_7.4p1 Debian-10+deb9u4 pat OpenSSH* compat 0x04000000
> debug1: Authenticating to 192.168.8.3:50400 as 'backuppc'
> debug1: SSH2_MSG_KEXINIT sent
> debug1: SSH2_MSG_KEXINIT received
> debug1: kex: algorithm: curve25519-sha256@libssh.org
> debug1: kex: host key algorithm: ssh-ed25519
> debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC:
> <implicit> compression: none
> debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC:
> <implicit> compression: none
> debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
> debug1: Server host key: ssh-ed25519
> SHA256:Qmmw9Hw9F68Lv9vTJTHpbJtwOzxUxod4FFAnA16D5bk
> debug1: Host '[192.168.8.3]:50400' is known and matches the ED25519 host
> key.
> debug1: Found key in /usr/local/BackupPC/.ssh/known_hosts:1
> debug1: rekey after 134217728 blocks
> debug1: SSH2_MSG_NEWKEYS sent
> debug1: expecting SSH2_MSG_NEWKEYS
> debug1: SSH2_MSG_NEWKEYS received
> debug1: rekey after 134217728 blocks
> debug1: SSH2_MSG_EXT_INFO received
> debug1: kex_input_ext_info:
> server-sig-algs=<ssh-ed25519,ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
> debug1: SSH2_MSG_SERVICE_ACCEPT received
> debug1: Authentications that can continue: publickey
> debug1: Next authentication method: publickey
> debug1: Offering ED25519 public key:
> /usr/local/BackupPC/.ssh/sirius_bpc-id_ed25519
> debug1: Server accepts key: pkalg ssh-ed25519 blen 51
> debug1: Offering RSA public key: /usr/local/BackupPC/.ssh/sirius_bpc-id_rsa
> debug1: Server accepts key: pkalg ssh-rsa blen 535
> debug1: No more authentication methods to try.
> Permission denied (publickey).
> backuppc@sirius:~$
> ____________
> as root :
> 
> root@sirius:~# whoami
> root
> root@sirius:~# hostname
> sirius
> root@sirius:~# cat /etc/debian_version
> 9.6
> root@sirius:~# uname -a
> Linux sirius 4.9.0-8-amd64 #1 SMP Debian 4.9.130-2 (2018-10-27) x86_64
> GNU/Linux
> root@sirius:~# dpkg-query -W openssh-client
> openssh-client    1:7.4p1-10+deb9u4
> 
> root@sirius:~# ls -aFl /usr/local/BackupPC/.ssh
> total 36
> drwx------ 2 backuppc backuppc 4096 Nov 13 12:08 ./
> drwxr-xr-x 6 backuppc backuppc 4096 Nov 13 12:12 ../
> -rw------- 1 backuppc backuppc 1790 Nov 13 12:04 authorized_keys
> -rw-r----- 1 backuppc backuppc 2240 Nov 13 12:02 config
> -rw-r--r-- 1 backuppc backuppc  142 Nov 13 12:08 known_hosts
> -rw------- 1 backuppc backuppc  484 Nov 13 12:03 sirius_bpc-id_ed25519
> -rw-r----- 1 backuppc backuppc  126 Nov 13 12:03 sirius_bpc-id_ed25519.pub
> -rw------- 1 backuppc backuppc 3479 Nov 13 12:04 sirius_bpc-id_rsa
> -rw-r----- 1 backuppc backuppc  770 Nov 13 12:04 sirius_bpc-id_rsa.pub
> 
> root@sirius:~# grep backuppc@sirius
> /usr/local/BackupPC/.ssh/authorized_keys
> ssh-ed25519
> AAAAC3NzaC1lZDI1NTE5AAAAIBIG1jFCDbjX1AuKEpi3U0rPtxW79kZwcEAzN+shbnni
> Generated on 181113.1203 for backuppc@sirius
> ssh-rsa
> AAAAB3NzaC1yc2EAAAADAQABAAACAQD2fiZLF9Q0+RKERleUw2LnoEXF3FdF/UPPX+khWUVIc+SWG+mTSIlFeEWNeoLpa32Vfb0T8cNooMgR6sodxQZlzC15ByPSotW7AHAdBylzkP0G4GM4zTYlkfuIzeJClNrNuphzbdIa8dH9xhmhqE7FbHcq34LErQX1zBfGcDVyqUABVdXTLqtDKRS2P3hCQ8gR8u0BDesvTUYWPwJXkXaq9UdS9VWsJuyQhnqzFKOm+cPdoqRFtvVAIxlqAyI9ok7d/cve4nIjFPg1n7ralTw4x8D4oxmOpUNqOC4dJYDCbihY3nImq0oB/+zt6uS3t232qjaUGrt0pUB2AywQwULYhGhAsiqGEaoJuuYUonCXT4IHxTIBFJraVSvr53gcM7Jm9kBcLG8x2B5rtiZzBImITv+nZnqTJgBu5q+ZBqm5FK4miBHjinscXxqCLmljXOW7Ui7uhg1NjcYMdaC1BRJoHzsTkIvnoRmONdUbDCK63n9MHikiRrvdme8SUQDjuKHfS5nNMClDfMF69Rgr27QkqOMOYYA2mqvcrjxtXS1n9DA88dnhCKsHfTDXCto710CHzQPh7YuUzlL8uNAE4RwzhOCDxgaI4WV9/qj2J+0C2PE0dkTwFqBuGytyBYFglpIhmnlucukdccZ5i/YpEkITvccB7EO/sPSRzAnm55iGUw==
> Generated on 181113.1203 for backuppc@sirius
> 
> root@sirius:~# tail -n 20 /var/log/auth.log
> Nov 13 12:28:07 sirius sshd[2159]: debug1: fd 4 clearing O_NONBLOCK
> Nov 13 12:28:07 sirius sshd[2159]: debug2: user_key_allowed: check options:
> 'ssh-ed25519
> AAAAC3NzaC1lZDI1NTE5AAAAIBIG1jFCDbjX1AuKEpi3U0rPtxW79kZwcEAzN+shbnni
> Generated on 181113.1203 for backuppc@sirius\n'
> Nov 13 12:28:07 sirius sshd[2159]: debug2: user_key_allowed: advance:
> 'AAAAC3NzaC1lZDI1NTE5AAAAIBIG1jFCDbjX1AuKEpi3U0rPtxW79kZwcEAzN+shbnni
> Generated on 181113.1203 for backuppc@sirius\n'
> Nov 13 12:28:07 sirius sshd[2159]: debug1: matching key found: file
> /usr/local/BackupPC/.ssh/authorized_keys, line 2 RSA
> SHA256:/TFnCvwpyL6W0Z4I71jw9u3eY4rWqB9lnHVSx3mdYNM
> Nov 13 12:28:07 sirius sshd[2159]: debug1: restore_uid: 0/0
> Nov 13 12:28:07 sirius sshd[2159]: debug3: mm_answer_keyallowed: key
> 0x55f0b985d0d0 is allowed
> Nov 13 12:28:07 sirius sshd[2159]: debug3: mm_request_send entering: type 23
> Nov 13 12:28:07 sirius sshd[2159]: debug3: send packet: type 60 [preauth]
> Nov 13 12:28:07 sirius sshd[2159]: debug2: userauth_pubkey: authenticated 0
> pkalg ssh-rsa [preauth]
> Nov 13 12:28:07 sirius sshd[2159]: Postponed publickey for backuppc from
> 192.168.8.3 port 48708 ssh2 [preauth]
> Nov 13 12:28:07 sirius sshd[2159]: Connection closed by 192.168.8.3 port
> 48708 [preauth]
> Nov 13 12:28:07 sirius sshd[2159]: debug1: do_cleanup [preauth]
> Nov 13 12:28:07 sirius sshd[2159]: debug3: PAM: sshpam_thread_cleanup
> entering [preauth]
> Nov 13 12:28:07 sirius sshd[2159]: debug1: monitor_read_log: child log fd
> closed
> Nov 13 12:28:07 sirius sshd[2159]: debug3: mm_request_receive entering
> Nov 13 12:28:07 sirius sshd[2159]: debug1: do_cleanup
> Nov 13 12:28:07 sirius sshd[2159]: debug1: PAM: cleanup
> Nov 13 12:28:07 sirius sshd[2159]: debug3: PAM: sshpam_thread_cleanup
> entering
> Nov 13 12:28:07 sirius sshd[2159]: debug1: Killing privsep child 2160
> Nov 13 12:28:07 sirius sshd[2159]: debug1: audit_event: unhandled event 12
> root@sirius:~#
> 
> On Tue, 13 Nov 2018 at 11:22, David Christensen <dpchrist@holgerdanske.com>
> wrote:
> 
>> On 11/12/18 5:49 AM, Alan Taylor wrote:
>>> Greetings,
>>
>> Hi.  :-)
>>
>>
>>> I have an ssh problem - one user can use it successfully, another
>> cannot. I have checked and rechecked permissions until I am blue in the
>> face …
>>> At the moment just trying to ssh into the same machine I am on for the
>> problem user (the other user can ssh successfully, both to the console
>> machine and outwards to others).
>>> Agent problem ? The successful user was setup in the installation, the
>> problem user was added at the command line after initial setup.
>>
>> Trouble-shooting can be tedious...
>>
>>
>>> Log output follows, appears to fail after the preauth stage …
>>>
>>> Any suggestions gratefully accepted
>>>
>>> root@sirius/etc/ssh # journalctl | grep sshd | grep "Nov 12 13:45"
>> <snip>
>>
>>
>> I would enter the following commands into the indicated accounts and
>> computers, substituting place holders with actual values (USERNAME,
>> SSH_CLIENT, SSH_SERVER).  If you still don't see it, cut and paste your
>> console sessions into a reply:
>>
>> 1.  As the user having problems on the computer having problems:
>>
>>          $ whoami
>>
>>          $ hostname
>>
>>          $ cat /etc/debian_version
>>
>>          $ uname -a
>>
>>          $ dpkg-query -W openssh-client
>>
>>          $ ls -aFl /home/USERNAME/.ssh
>>
>>          $ ssh -v SSH_SERVER
>>
>> 2.  As root on the SSH server:
>>
>>          # hostname
>>
>>          # cat /etc/debian_version
>>
>>          # uname -a
>>
>>          # dpkg-query -W openssh-server
>>
>>          # ls -aFl /home/USERNAME/.ssh
>>
>>          # grep USERNAME@SSH_CLIENT /home/USERNAME/.ssh/authorized_keys
>>
>>          # tail /var/log/auth.log
>>
>>
>> David
>>
>>

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

#202451

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

Success … sort of.

Removing "BatchMode yes” from the backuppc users .ssh/config file fixed everything EXCEPT
the backuppc user still could not ssh out from the backup computer (sirius) to other computers.
However, the error message was now a lot clearer (complaining that login not allowed because the account was locked).
All of the client computers have a backuppc user with the shell set to /bin/false (the recommended procedure) as there is no shell login required on these computers.
However, changing this to /bin/bash solved the problem … backuppc user can now ssh from the backup computer (sirius) to others.

Any ideas as to what may be causing this last issue ?

PS UsePam is set to yes

BRgds/Alan

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

#202484

On 11/14/18 10:13 PM, Alan Taylor wrote:
> Success … sort of.
> 
> Removing "BatchMode yes” from the backuppc users .ssh/config file fixed everything EXCEPT
> the backuppc user still could not ssh out from the backup computer (sirius) to other computers.
> However, the error message was now a lot clearer (complaining that login not allowed because the account was locked).
> All of the client computers have a backuppc user with the shell set to /bin/false (the recommended procedure) as there is no shell login required on these computers.
> However, changing this to /bin/bash solved the problem … backuppc user can now ssh from the backup computer (sirius) to others.
> 
> Any ideas as to what may be causing this last issue ?
> 
> PS UsePam is set to yes


If you want to log in to an account whose /etc/passwd shell is 
/bin/false, one trick is to su(1) to root, then su(1) to that account 
using the '--shell' option:

     2018-11-15 09:17:06 root@tinkywinky ~
     # grep ntp /etc/passwd
     ntp:x:118:124::/home/ntp:/bin/false

     2018-11-15 09:17:10 root@tinkywinky ~
     # su -l -s /bin/bash ntp
     No directory, logging in with HOME=/
     ntp@tinkywinky:/$


Can backuppc on one "other" computer log into another "other" computer?


It would help if you posted your console session indicating source 
machine (prompt), command issued, and output displayed.


It would help if you posted the active lines in ~/.ssh/config, 
/etc/ssh/ssh_config, and /etc/ssh/sshd_config on the relevant machines:

     $ grep . ~/.ssh/config | grep -v '#'

     $ grep . /etc/ssh/ssh_config | grep -v '#'

     $ grep . /etc/ssh/sshd_config | grep -v '#'


David

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

#202550

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

Thanks Everyone.

I am getting that together to show you.

A question though - are you sure this is not normal behavior ?
Most of my research on the net (with caution I know) seems to suggest that ssh disconnection after authentication because of /bin/false is normal ?

BRgds/Alan
On 16 Nov 2018, 01:23 +0800, David Christensen <dpchrist@holgerdanske.com>, wrote:
> On 11/14/18 10:13 PM, Alan Taylor wrote:
> > Success … sort of.
> >
> > Removing "BatchMode yes” from the backuppc users .ssh/config file fixed everything EXCEPT
> > the backuppc user still could not ssh out from the backup computer (sirius) to other computers.
> > However, the error message was now a lot clearer (complaining that login not allowed because the account was locked).
> > All of the client computers have a backuppc user with the shell set to /bin/false (the recommended procedure) as there is no shell login required on these computers.
> > However, changing this to /bin/bash solved the problem … backuppc user can now ssh from the backup computer (sirius) to others.
> >
> > Any ideas as to what may be causing this last issue ?
> >
> > PS UsePam is set to yes
>
>
> If you want to log in to an account whose /etc/passwd shell is
> /bin/false, one trick is to su(1) to root, then su(1) to that account
> using the '--shell' option:
>
> 2018-11-15 09:17:06 root@tinkywinky ~
> # grep ntp /etc/passwd
> ntp:x:118:124::/home/ntp:/bin/false
>
> 2018-11-15 09:17:10 root@tinkywinky ~
> # su -l -s /bin/bash ntp
> No directory, logging in with HOME=/
> ntp@tinkywinky:/$
>
>
> Can backuppc on one "other" computer log into another "other" computer?
>
>
> It would help if you posted your console session indicating source
> machine (prompt), command issued, and output displayed.
>
>
> It would help if you posted the active lines in ~/.ssh/config,
> /etc/ssh/ssh_config, and /etc/ssh/sshd_config on the relevant machines:
>
> $ grep . ~/.ssh/config | grep -v '#'
>
> $ grep . /etc/ssh/ssh_config | grep -v '#'
>
> $ grep . /etc/ssh/sshd_config | grep -v '#'
>
>
> David
>
>

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

#202578

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

On 17/11/2018 04:28, Alan Taylor wrote:
> Thanks Everyone.
>
> I am getting that together to show you.
>
> A question though - are you sure this is not normal behavior ?
> Most of my research on the net (with caution I know) seems to suggest 
> that ssh disconnection after authentication because of /bin/false is 
> normal ?
>
>
Yes, it is normal. A user with /bin/false as his ahell should not be 
able to login. These days www-data has /bin/false too, which caught be 
out, until I changed it back.

-- 
Mike Howard

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

#202593

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

Thanks Mike,

I was slowly coming to that conclusion !
What would be best practice regarding a password for that account (i.e. system account such as backuppc that needs ssh access but no shell access).

If I create the user with bash as the shell, I seem to have a few options:
1) don’t set a password (i.e. no reference to password in the adduer command). The man page says this results in the password being “disabled”. What does this actually mean for security ?
2) use —disabled-password (same as 1 above ?)
3) the —disabled-password option appears to be only available on debian. Redhat derivatives only offer useradd which does not have this switch ?

Which would be the most secure, while still allowing ssh access ?

BRgds/Alan
On 18 Nov 2018, 19:50 +0800, Michael Howard <mike@dewberryfields.co.uk>, wrote:
> On 17/11/2018 04:28, Alan Taylor wrote:
> > Thanks Everyone.
> >
> > I am getting that together to show you.
> >
> > A question though - are you sure this is not normal behavior ?
> > Most of my research on the net (with caution I know) seems to suggest that ssh disconnection after authentication because of /bin/false is normal ?
> >
> >
> Yes, it is normal. A user with /bin/false as his ahell should not be able to login. These days www-data has /bin/false too, which caught be out, until I changed it back.
> --
> Mike Howard

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

#202597

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

On 19/11/2018 02:46, Alan Taylor wrote:
> Thanks Mike,
>
> I was slowly coming to that conclusion !
> What would be best practice regarding a password for that account 
> (i.e. system account such as backuppc that needs ssh access but no 
> shell access).
>
> If I create the user with bash as the shell, I seem to have a few options:
> 1) don’t set a password (i.e. no reference to password in the adduer 
> command). The man page says this results in the password being 
> “disabled”. What does this actually mean for security ?
> 2) use —disabled-password (same as 1 above ?)
> 3) the —disabled-password option appears to be only available on 
> debian. Redhat derivatives only offer useradd which does not have this 
> switch ?
>
> Which would be the most secure, while still allowing ssh access ?
>
>

Don't get too hung up on it all.

If the account needs login access then give it. Create or use an account 
with a shell of your choice and a secure password. You don't need to 
remember the password, as you are using keys, so it can be ridiculously 
secure. A standard user cant do much harm if you don't give it any more 
privileges than it needs.

-- 
Mike Howard

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

#202599

On 11/19/2018 8:28 AM, Michael Howard wrote:
> On 19/11/2018 02:46, Alan Taylor wrote:
>> Thanks Mike,
>>
>> I was slowly coming to that conclusion !
>> What would be best practice regarding a password for that account
>> (i.e. system account such as backuppc that needs ssh access but no
>> shell access).
>>
>> If I create the user with bash as the shell, I seem to have a few
>> options:
>> 1) don’t set a password (i.e. no reference to password in the adduer
>> command). The man page says this results in the password being
>> “disabled”. What does this actually mean for security ?
>> 2) use —disabled-password (same as 1 above ?)
>> 3) the —disabled-password option appears to be only available on
>> debian. Redhat derivatives only offer useradd which does not have this
>> switch ?
>>
>> Which would be the most secure, while still allowing ssh access ?
>>
>>
> 
> Don't get too hung up on it all.
> 
> If the account needs login access then give it. Create or use an account
> with a shell of your choice and a secure password. You don't need to
> remember the password, as you are using keys, so it can be ridiculously
> secure. A standard user cant do much harm if you don't give it any more
> privileges than it needs.
> 

Some hints to better secure your setup:

Locking the password of the named accound (1).
In '/etc/ssh/sshd_config' using an 'match' condition (2) to only allow
public key.
Further restricting the allowd commands in authorized_keys file (3,
Format of the Authorized Keys File).


1)  http://man7.org/linux/man-pages/man1/passwd.1.html
2)  https://linux.die.net/man/5/sshd_config
3)
https://www.ssh.com/ssh/authorized_keys/openssh#sec-Format-of-the-Authorized-Keys-File


Note that this e-mail is folded by my mailer.
-- 
John Doe

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

#202608

On Mon, Nov 19, 2018 at 08:32:09AM -0500, Greg Wooledge wrote:
>On Mon, Nov 19, 2018 at 07:28:15AM +0000, Michael Howard wrote:
>> Don't get too hung up on it all.
>>
>> If the account needs login access then give it. Create or use an account
>> with a shell of your choice and a secure password. You don't need to
>> remember the password, as you are using keys, so it can be ridiculously
>> secure.
>
>If you're only going to login to the account using ssh keys, you don't
>need to give it a valid password hash at all.  Just put a string of
>rubbish (English words qualify) in the hash field of /etc/shadow.

Don't do that. Just use a *.

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

#202611

On Mon, 2018-11-19 at 08:38 -0500, Michael Stone wrote:
> On Mon, Nov 19, 2018 at 08:32:09AM -0500, Greg Wooledge wrote:
> > If you're only going to login to the account using ssh keys, you
> > don't need to give it a valid password hash at all.  Just put a
> > string of rubbish (English words qualify) in the hash field of
> > /etc/shadow.
> 
> Don't do that. Just use a *.

Something that's always bugged me... is there any difference between
using * or ! (both are valid)?

-Jim P.

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

#202618

On Mon, Nov 19, 2018 at 09:43:29AM -0500, Jim Popovitch wrote:
>On Mon, 2018-11-19 at 08:38 -0500, Michael Stone wrote:
>> On Mon, Nov 19, 2018 at 08:32:09AM -0500, Greg Wooledge wrote:
>> > If you're only going to login to the account using ssh keys, you
>> > don't need to give it a valid password hash at all.  Just put a
>> > string of rubbish (English words qualify) in the hash field of
>> > /etc/shadow.
>>
>> Don't do that. Just use a *.
>
>Something that's always bugged me... is there any difference between
>using * or ! (both are valid)?

! locks the account, * is a convention that means "no password".

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

#202620

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

On Mon, 2018-11-19 at 12:12 -0500, Michael Stone wrote:
> On Mon, Nov 19, 2018 at 09:43:29AM -0500, Jim Popovitch wrote:
> > On Mon, 2018-11-19 at 08:38 -0500, Michael Stone wrote:
> > > On Mon, Nov 19, 2018 at 08:32:09AM -0500, Greg Wooledge wrote:
> > > > If you're only going to login to the account using ssh keys, you
> > > > don't need to give it a valid password hash at all.  Just put a
> > > > string of rubbish (English words qualify) in the hash field of
> > > > /etc/shadow.
> > > 
> > > Don't do that. Just use a *.
> > 
> > Something that's always bugged me... is there any difference between
> > using * or ! (both are valid)?
> 
> ! locks the account, * is a convention that means "no password".
> 

Ack!  Thanks!

-Jim P.

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

#202626

On Mon, Nov 19, 2018 at 12:12:50PM -0500, Michael Stone wrote:
>On Mon, Nov 19, 2018 at 09:43:29AM -0500, Jim Popovitch wrote:
>>On Mon, 2018-11-19 at 08:38 -0500, Michael Stone wrote:
>>>On Mon, Nov 19, 2018 at 08:32:09AM -0500, Greg Wooledge wrote:
>>>> If you're only going to login to the account using ssh keys, you
>>>> don't need to give it a valid password hash at all.  Just put a
>>>> string of rubbish (English words qualify) in the hash field of
>>>> /etc/shadow.
>>>
>>>Don't do that. Just use a *.
>>
>>Something that's always bugged me... is there any difference between
>>using * or ! (both are valid)?
>
>! locks the account, * is a convention that means "no password".

I should clarify that a bit: a ! locked account can't be used at all 
(assuming that all login methods respect that convention) whereas the * 
account can't use password authentication but may be able to use other 
mechanisms like ssh keys. A completely blank field indicates an empty 
password.

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

#202609

On Mon, Nov 19, 2018 at 07:28:15AM +0000, Michael Howard wrote:
> Don't get too hung up on it all.
> 
> If the account needs login access then give it. Create or use an account
> with a shell of your choice and a secure password. You don't need to
> remember the password, as you are using keys, so it can be ridiculously
> secure.

If you're only going to login to the account using ssh keys, you don't
need to give it a valid password hash at all.  Just put a string of
rubbish (English words qualify) in the hash field of /etc/shadow.

According to shadow(5):

           If the password field contains some string that is not a valid
           result of crypt(3), for instance ! or *, the user will not be able
           to use a unix password to log in (but the user may log in the
           system by other means).
         [...]
           A password field which starts with an exclamation mark means that
           the password is locked. The remaining characters on the line
           represent the password field before the password was locked.

So, just make sure you don't start it with a bang, and you should be OK.

[toc] | [prev] | [standalone]

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

csiph-web