- Date: Sat, 17 Nov 2018 12:28:46 +0800
- From: Alan Taylor <alan.james.taylor@xxxxxxxxx>
- Subject: Re: ssh
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 ?
On 16 Nov 2018, 01:23 +0800, David Christensen <dpchrist@xxxxxxxxxxxxxxxx>, 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
2018-11-15 09:17:10 root@tinkywinky ~
# su -l -s /bin/bash ntp
No directory, logging in with HOME=/
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 '#'
- Re: ssh
- From: Michael Howard
- Re: ssh