LinuxQuestions.org - Last night upgrades can no longer login

- Slackware - ARM (https://www.linuxquestions.org/questions/slackware-arm-108/)

- - Last night upgrades can no longer login (https://www.linuxquestions.org/questions/slackware-arm-108/last-night-upgrades-can-no-longer-login-4175552555/)

Last night upgrades can no longer login

I ran slackpkg update and upgrade-all last night and now I can no longer login to either of my Raspebrry Pi's, they both tell me my password is wrong? Is there a way to log in now and recover?

Use single user mode.

I'd have to buy a monitor, both I setup headless.
I did find that I can ssh in via another account and su to root without issues on one, which makes me think a config file changed (IIRC thats a setting in SSH). So I can get in one but the other I don't have another account to use.
I'm wondering why the SSH setting would have changed.

Config file looks like this:

Code:

#PermitRootLogin yes

I bet they changed the default in ssh so if the setting is not specified (as above where its commented out) it now defaults to no.

Quote:

Originally Posted by enine (Post 5415498)

Code:

#PermitRootLogin yes

I bet they changed the default in ssh so if the setting is not specified (as above where its commented out) it now defaults to no.

I don't know which version of sshd you upgraded from, but the version (7.0p1) prior to the latest batch (7.1p1), has this default according to the man page of sshd_config:

Code:

  PermitRootLogin

            Specifies whether root can log in using ssh(1).  The argument must be ``yes'', ``prohibit-password'', ``without-password'', ``forced-commands-only'', or ``no''.  The

            default is ``prohibit-password''.

So if you had 'PermitRootLogin yes' commented out as you have shown above, I'm not sure how you logged in as root to begin with.
Also, if the /etc/ssh/sshd_config file is different from the incoming version in the new package you're upgrading to, it'll move the incoming version to sshd_config.new. Therefore if you had an sshd_config that did allow you to explicitly login as root, you'd still be able to do so.

As for fixing it - can't you boot in to the installer using the serial console?

Thats the only thing I can thing of that is preventing it. I see its commented out in both the original and .new config file. I wonder if there was a bug in the old version and it was allowing even if it was commented out. I didn't change that from the Slackware install.

Quote:

Originally Posted by enine (Post 5415498)

Config file looks like this:

Code:

#PermitRootLogin yes

I never allow root to login remotely on any of my Slackware systems.

Couldn't you just mount the sd card partitions on the rpi that is allowing you to login and edit the sshd_config file that way?

Yea, I just don't want to hard shutdown the other one, mysql tends to not like that

Quote:

Originally Posted by enine (Post 5415678)

It's possible but unlikely - I expect that someone would have noticed if they could login as root without the config being set.
If you find out what it is, let me know since we want to try and avoid these kinds of problems during the upgrade from 14.1 to 14.2. Pat's going to make some changes to the doinst.sh script to try and aid the transition, but I don't think it'd have caught whatever this problem is.

Old sshd_config dated 12/9/2014

Code:

#        $OpenBSD: sshd_config,v 1.93 2014/01/10 05:59:19 djm Exp $



# This is the sshd server system-wide configuration file.  See

# sshd_config(5) for more information.



# This sshd was compiled with PATH=/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin



# The strategy used for options in the default sshd_config shipped with

# OpenSSH is to specify options with their default value where

# possible, but leave them commented.  Uncommented options override the

# default value.



#Port 22

#AddressFamily any

#ListenAddress 0.0.0.0

#ListenAddress ::



# The default requires explicit activation of protocol 1

#Protocol 2



# HostKey for protocol version 1

#HostKey /etc/ssh/ssh_host_key

# HostKeys for protocol version 2

#HostKey /etc/ssh/ssh_host_rsa_key

#HostKey /etc/ssh/ssh_host_dsa_key

#HostKey /etc/ssh/ssh_host_ecdsa_key

#HostKey /etc/ssh/ssh_host_ed25519_key



# Lifetime and size of ephemeral version 1 server key

#KeyRegenerationInterval 1h

#ServerKeyBits 1024



# Ciphers and keying

#RekeyLimit default none



# Logging

# obsoletes QuietMode and FascistLogging

#SyslogFacility AUTH

#LogLevel INFO



# Authentication:



#LoginGraceTime 2m

#PermitRootLogin yes

#StrictModes yes

#MaxAuthTries 6

#MaxSessions 10



#RSAAuthentication yes

#PubkeyAuthentication yes



# The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2

# but this is overridden so installations will only check .ssh/authorized_keys

AuthorizedKeysFile        .ssh/authorized_keys



#AuthorizedPrincipalsFile none



#AuthorizedKeysCommand none

#AuthorizedKeysCommandUser nobody



# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts

#RhostsRSAAuthentication no

# similar for protocol version 2

#HostbasedAuthentication no

# Change to yes if you don't trust ~/.ssh/known_hosts for

# RhostsRSAAuthentication and HostbasedAuthentication

#IgnoreUserKnownHosts no

# Don't read the user's ~/.rhosts and ~/.shosts files

#IgnoreRhosts yes



# To disable tunneled clear text passwords, change to no here!

#PasswordAuthentication yes

#PermitEmptyPasswords no



# Change to no to disable s/key passwords

#ChallengeResponseAuthentication yes



# Kerberos options

#KerberosAuthentication no

#KerberosOrLocalPasswd yes

#KerberosTicketCleanup yes

#KerberosGetAFSToken no



# GSSAPI options

#GSSAPIAuthentication no

#GSSAPICleanupCredentials yes



# Set this to 'yes' to enable PAM authentication, account processing,

# and session processing. If this is enabled, PAM authentication will

# be allowed through the ChallengeResponseAuthentication and

# PasswordAuthentication.  Depending on your PAM configuration,

# PAM authentication via ChallengeResponseAuthentication may bypass

# the setting of "PermitRootLogin without-password".

# If you just want the PAM account and session checks to run without

# PAM authentication, then enable this but set PasswordAuthentication

# and ChallengeResponseAuthentication to 'no'.

#UsePAM no



#AllowAgentForwarding yes

#AllowTcpForwarding yes

#GatewayPorts no

#X11Forwarding no

#X11DisplayOffset 10

#X11UseLocalhost yes

#PermitTTY yes

#PrintMotd yes

#PrintLastLog yes

#TCPKeepAlive yes

#UseLogin no

UsePrivilegeSeparation sandbox                # Default for new installations.

#PermitUserEnvironment no

#Compression delayed

#ClientAliveInterval 0

#ClientAliveCountMax 3

#UseDNS yes

#PidFile /var/run/sshd.pid

#MaxStartups 10:30:100

#PermitTunnel no

#ChrootDirectory none

#VersionAddendum none



# no default banner path

#Banner none



# override default of no subsystems

Subsystem        sftp        /usr/libexec/sftp-server



# Example of overriding settings on a per-user basis

#Match User anoncvs

#        X11Forwarding no

#        AllowTcpForwarding no

#        PermitTTY no

#        ForceCommand cvs server

New sshd_config dated 8/12/2015

Code:

#        $OpenBSD: sshd_config,v 1.97 2015/08/06 14:53:21 deraadt Exp $



# This is the sshd server system-wide configuration file.  See

# sshd_config(5) for more information.



# This sshd was compiled with PATH=/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin



# The strategy used for options in the default sshd_config shipped with

# OpenSSH is to specify options with their default value where

# possible, but leave them commented.  Uncommented options override the

# default value.



#Port 22

#AddressFamily any

#ListenAddress 0.0.0.0

#ListenAddress ::



# The default requires explicit activation of protocol 1

#Protocol 2



# HostKey for protocol version 1

#HostKey /etc/ssh/ssh_host_key

# HostKeys for protocol version 2

#HostKey /etc/ssh/ssh_host_rsa_key

#HostKey /etc/ssh/ssh_host_dsa_key

#HostKey /etc/ssh/ssh_host_ecdsa_key

#HostKey /etc/ssh/ssh_host_ed25519_key



# Lifetime and size of ephemeral version 1 server key

#KeyRegenerationInterval 1h

#ServerKeyBits 1024



# Ciphers and keying

#RekeyLimit default none



# Logging

# obsoletes QuietMode and FascistLogging

#SyslogFacility AUTH

#LogLevel INFO



# Authentication:



#LoginGraceTime 2m

#PermitRootLogin prohibit-password

#StrictModes yes

#MaxAuthTries 6

#MaxSessions 10



#RSAAuthentication yes

#PubkeyAuthentication yes



# The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2

# but this is overridden so installations will only check .ssh/authorized_keys

AuthorizedKeysFile        .ssh/authorized_keys



#AuthorizedPrincipalsFile none



#AuthorizedKeysCommand none

#AuthorizedKeysCommandUser nobody



# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts

#RhostsRSAAuthentication no

# similar for protocol version 2

#HostbasedAuthentication no

# Change to yes if you don't trust ~/.ssh/known_hosts for

# RhostsRSAAuthentication and HostbasedAuthentication

#IgnoreUserKnownHosts no

# Don't read the user's ~/.rhosts and ~/.shosts files

#IgnoreRhosts yes



# To disable tunneled clear text passwords, change to no here!

#PasswordAuthentication yes

#PermitEmptyPasswords no



# Change to no to disable s/key passwords

#ChallengeResponseAuthentication yes



# Kerberos options

#KerberosAuthentication no

#KerberosOrLocalPasswd yes

#KerberosTicketCleanup yes

#KerberosGetAFSToken no



# GSSAPI options

#GSSAPIAuthentication no

#GSSAPICleanupCredentials yes



# Set this to 'yes' to enable PAM authentication, account processing,

# and session processing. If this is enabled, PAM authentication will

# be allowed through the ChallengeResponseAuthentication and

# PasswordAuthentication.  Depending on your PAM configuration,

# PAM authentication via ChallengeResponseAuthentication may bypass

# the setting of "PermitRootLogin without-password".

# If you just want the PAM account and session checks to run without

# PAM authentication, then enable this but set PasswordAuthentication

# and ChallengeResponseAuthentication to 'no'.

#UsePAM no



#AllowAgentForwarding yes

#AllowTcpForwarding yes

#GatewayPorts no

#X11Forwarding no

#X11DisplayOffset 10

#X11UseLocalhost yes

#PermitTTY yes

#PrintMotd yes

#PrintLastLog yes

#TCPKeepAlive yes

#UseLogin no

UsePrivilegeSeparation sandbox                # Default for new installations.

#PermitUserEnvironment no

#Compression delayed

#ClientAliveInterval 0

#ClientAliveCountMax 3

#UseDNS no

#PidFile /var/run/sshd.pid

#MaxStartups 10:30:100

#PermitTunnel no

#ChrootDirectory none

#VersionAddendum none



# no default banner path

#Banner none



# override default of no subsystems

Subsystem        sftp        /usr/libexec/sftp-server



# Example of overriding settings on a per-user basis

#Match User anoncvs

#        X11Forwarding no

#        AllowTcpForwarding no

#        PermitTTY no

#        ForceCommand cvs server

Notice the PermitRootLogin is commented in both but I was able to login before. I do see the comments at the top of the new file says the options listed and commented are the defaults and that they added prohibitpassword in the .new file which implies that is the default now.
Well their bsd sshd man page says the default is No.

Hey, I'm not completely crazy after all

Quote:

Changes since OpenSSH 7.0
=========================

This is a bugfix release.

Security
--------

* sshd(8): OpenSSH 7.0 contained a logic error in PermitRootLogin=
prohibit-password/without-password that could, depending on
compile-time configuration, permit password authentication to
root while preventing other forms of authentication. This problem
was reported by Mantas Mikulenas.

http://www.openssh.com/txt/release-7.1

Looks like we had 6.7 before looking at my last -current download. Maybe there were more changes prior, it tells me at very least they were fscking with that portion.

Quote:

Originally Posted by drmozes (Post 5416162)

let me know since we want to try and avoid these kinds of problems during the upgrade from 14.1 to 14.2.

Wait, did we just get a hint as to the next release of Slackware being 14.2? :)

No 14.42 to follow in 13.37's footsteps huh?

Uh! oh! That PermitRootLogin option made me out of my OrangePI cutie, too...

I was forced to mount the harddisk in a PC and to edit by hand that option. :)

BTW, OrangePI works very similar with BananaPI, having as plus, the native VGA output. A very useful thingy considering that I use for it a cheap and so old 15" LCD monitor, with native resolution of 1280x720 (that's normal HD, if I remember right). :hattip:

Quote:

Originally Posted by Darth Vader (Post 5416694)

*laughs* Slow news day on LQ, I take it? :-)
Your posts make me laugh.

As for 14.2 as for the version, yes.

BTW, I have two 10" netbooks, one is a WM8650, another a WM8850. Also a Cubieboard2 (Allwinner-A20), a BananaPI and one OrangePI. In those I have managed to run Slackware ARM. To be precise, using the Android kernels and modules, "borrowed" from their original Android systems. In fact, that's my principle: use the Android kernels, if possible. Right now, only BananaPI run your shipped kernel, being used as a file-server.

Also, I have another 9" WM8880 netbook, and some TV boxes, one is RK3066, another is RK3188, which I has with not luck to run Slackware on them, and I use them, literally, as Android TV boxes, i.e. the MK808B (RK3066 driven) I use as secondary (Android) system, to watch movies and series, from a 3.5" 1TB external hard disk enclosure, on a 24" monitor.

Finally, right now I have some plans to buy an OrangePI Plus.

I wonder what make you to *laught* ... :hattip:

Quote:

Originally Posted by drmozes (Post 5416705)

As for 14.2 as for the version, yes.

So when will it release??? :p

And yes it was a simple matter to put my drive in another system and uncomment the line in the config, I just didn't want to have to yank the power from my Pi, mysql usually doesn't like that.

I got bit by that, too. OpenSSH no longer allows remote root login by default, although you can to a non-root remote login and then "su" to get root privs. And, philosophically and as a matter of security, it's the right thing to do anyway.