Root login ssh and weblish kicks me out
When logging into ubuntu server using weblish it logs me in then I get kick out and ask for the user and password again. When ssh I get invalid username or password. I reset my root password using settings in linode but still the same issue. How can I get back into my server if I cannot log into it with a root user?
18 Replies
I want to give you some resources here which should be able to help you out. The first is another post here in the Community that gives detailed steps for troubleshooting SSH issues:
Why can't I connect to my Linode via SSH?
Also, are you using root as the username when logging in as the root user? I only ask because I've seen it before where users attempted to use another username paired with the root password.
Let us know if this helps!
Tried some steps:
Trying Weblish I can login and then kicks me back out. I tried ssh -vvv and I get this. From what I can see on my computer it is trying to use a key to authenticate then a password. Either way I am not sure why Weblish is not even keeping me log in.
➜ ssh -vvv root@45.33.6.45
OpenSSH_8.1p1, LibreSSL 2.7.3
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 47: Applying options for *
debug2: resolve_canonicalize: hostname 45.33.6.45 is address
debug2: ssh_connect_direct
debug1: Connecting to 45.33.6.45 [45.33.6.45] port 22.
debug1: Connection established.
debug1: identity file /Users/jesusguzman/.ssh/id_rsa type -1
debug1: identity file /Users/jesusguzman/.ssh/id_rsa-cert type -1
debug1: identity file /Users/jesusguzman/.ssh/id_dsa type -1
debug1: identity file /Users/jesusguzman/.ssh/id_dsa-cert type -1
debug1: identity file /Users/jesusguzman/.ssh/id_ecdsa type -1
debug1: identity file /Users/jesusguzman/.ssh/id_ecdsa-cert type -1
debug1: identity file /Users/jesusguzman/.ssh/id_ed25519 type -1
debug1: identity file /Users/jesusguzman/.ssh/id_ed25519-cert type -1
debug1: identity file /Users/jesusguzman/.ssh/id_xmss type -1
debug1: identity file /Users/jesusguzman/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.2p1 Ubuntu-4ubuntu0.1
debug1: match: OpenSSH_8.2p1 Ubuntu-4ubuntu0.1 pat OpenSSH* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to 45.33.6.45:22 as 'root'
debug3: hostkeys_foreach: reading file "/Users/jesusguzman/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /Users/jesusguzman/.ssh/known_hosts:2
debug3: load_hostkeys: loaded 1 keys from 45.33.6.45
debug3: order_hostkeyalgs: prefer hostkeyalgs: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
debug3: receive packet: type 20
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,ext-info-c
debug2: host key algorithms: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519-cert-v01@openssh.com,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,zlib@openssh.com,zlib
debug2: compression stoc: none,zlib@openssh.com,zlib
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256
debug2: host key algorithms: rsa-sha2-512,rsa-sha2-256,ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519
debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,zlib@openssh.com
debug2: compression stoc: none,zlib@openssh.com
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
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
debug3: send packet: type 30
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug3: receive packet: type 31
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:uJG3n2CG2mkuUxjRFOJEPMP1tWugD960x+3hbGY3iT4
debug3: hostkeys_foreach: reading file "/Users/jesusguzman/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /Users/jesusguzman/.ssh/known_hosts:2
debug3: load_hostkeys: loaded 1 keys from 45.33.6.45
debug1: Host '45.33.6.45' is known and matches the ECDSA host key.
debug1: Found key in /Users/jesusguzman/.ssh/known_hosts:2
debug3: send packet: type 21
debug2: set_newkeys: mode 1
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: receive packet: type 21
debug1: SSH2_MSG_NEWKEYS received
debug2: set_newkeys: mode 0
debug1: rekey in after 134217728 blocks
debug1: Will attempt key: /Users/jesusguzman/.ssh/id_rsa
debug1: Will attempt key: /Users/jesusguzman/.ssh/id_dsa
debug1: Will attempt key: /Users/jesusguzman/.ssh/id_ecdsa
debug1: Will attempt key: /Users/jesusguzman/.ssh/id_ed25519
debug1: Will attempt key: /Users/jesusguzman/.ssh/id_xmss
debug2: pubkey_prepare: done
debug3: send packet: type 5
debug3: receive packet: type 7
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,sk-ssh-ed25519@openssh.com,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ecdsa-sha2-nistp256@openssh.com>
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /Users/jesusguzman/.ssh/id_rsa
debug3: no such identity: /Users/jesusguzman/.ssh/id_rsa: No such file or directory
debug1: Trying private key: /Users/jesusguzman/.ssh/id_dsa
debug3: no such identity: /Users/jesusguzman/.ssh/id_dsa: No such file or directory
debug1: Trying private key: /Users/jesusguzman/.ssh/id_ecdsa
debug3: no such identity: /Users/jesusguzman/.ssh/id_ecdsa: No such file or directory
debug1: Trying private key: /Users/jesusguzman/.ssh/id_ed25519
debug3: no such identity: /Users/jesusguzman/.ssh/id_ed25519: No such file or directory
debug1: Trying private key: /Users/jesusguzman/.ssh/id_xmss
debug3: no such identity: /Users/jesusguzman/.ssh/id_xmss: No such file or directory
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
root@45.33.6.45's password:
debug3: send packet: type 50
debug2: we sent a password packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password
Permission denied, please try again.</ssh-ed25519,sk-ssh-ed25519@openssh.com,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ecdsa-sha2-nistp256@openssh.com></implicit></implicit>
Based on that output it doesn't appear as though an authentication key-pair for SSH has been configured on your desktop. That shouldn't prevent you from accessing your server, though, unless there were changes made to your sshd_config file that would disallow root logins or password authentication. Either way, the typical process for solving these type of issues would be to access the server via Lish, so we'll focus on that first to work towards a resolution.
I was able to locate your server, and currently I’m not seeing any issues with Lish on the backend, nor am I able to replicate the issue you’re experiencing. Your boot logs also look unconcerning, so this problem is peculiar for sure. I’m curious if there are specific commands/actions you’re running that result in a Lish session termination?
You could try some of the below troubleshooting steps to see if any gain you access to your server:
- Connect to Lish through a Terminal Application
- Ensure you’re not experiencing any local network dropouts that would result in a termination of a Lish session.
- Check your browser for updates
- Try a different browser entirely
If that doesn’t lead to a resolve, it may be best to spin up a new Linode to see if you run into the same issue. If you choose to go this route, I recommend following the steps in our Getting Started and Securing Your Server for proper, secure setup of server access through SSH.
When using Lish through the terminal it authenticates and asks me for my username and password again. When I enter it again it does the same thing. I tried another Linode and it works without any problem.
Ubuntu 20.04.1 LTS localhost ttyS0
localhost login: root
Password:
Welcome to Ubuntu 20.04.1 LTS (GNU/Linux 5.4.0-58-generic x86_64)
Documentation: https://help.ubuntu.com
Management: https://landscape.canonical.com
Support: https://ubuntu.com/advantage
System information as of Wed 23 Dec 2020 04:36:59 PM UTC
System load: 0.0
Usage of /: 15.9% of 24.06GB
Memory usage: 15%
Swap usage: 0%
Processes: 96
Users logged in: 0
IPv4 address for eth0: 45.33.6.45
IPv6 address for eth0: 2600:3c00::f03c:92ff:fe06:e5efIntroducing self-healing high availability clusters in MicroK8s.
Simple, hardened, Kubernetes for production, from RaspberryPi to DC.
0 updates can be installed immediately.
0 of these updates are security updates.
Last login: Wed Dec 23 16:35:27 UTC 2020 on ttyS0
Ubuntu 20.04.1 LTS localhost ttyS0
localhost login:
To me this looks like two problems.
Regarding ssh - perhaps you're disallowing root to log in via ssh (a common practice). Check your sshd_config
on the server (via rescue mode, perhaps?).
Re the console logging you in, showing you the banner, then logging you out: it could be someone futzed with your ~/.bash_profile
or the like, and has a command in there to kick you out when an interactive shell is spawned.
HTH,
-Chris
When rebooting into rescue mode I have access again but then when rebooting back to normal mode it gives me the same issue.
Is there anything that I can do in rescue mode to fix this issue?
Boot into Rescue Mode, mount the disk, look at /$mountpoint/etc/ssh/sshd_config
for PermitRootLogin
and related lines.
Look at /$mountpoint/root/.bash_profile
, .bash_login, and .profile files and check that nobody added a command that would cause an interactive shell to exit on start.
-Chris
for sshd I get this:
GNU nano 4.9.3 finnix.conf
"Safe" for maintenance use since by default, the user needs to set a
root password and start ssh.service.
PasswordAuthentication yes
PermitRootLogin yes
Do not have .bash_profile or .bash_login. this is what I have:
root@finnix:~# ls -al
total 7
drwx------ 1 root root 100 Dec 23 17:07 .
drwxr-xr-x 1 root root 160 Dec 23 16:49 ..
-rw-r--r-- 1 root root 639 Aug 8 02:30 .bash_finnix
-rw-r--r-- 1 root root 220 Feb 25 2020 .bash_logout
-rw-r--r-- 1 root root 3601 Aug 8 02:30 .bashrc
drwx------ 3 root root 80 Dec 23 16:49 .gnupg
drwxr-xr-x 3 root root 60 Dec 23 16:59 .local
-rw-r--r-- 1 root root 807 Feb 25 2020 .profile
drwxr-xr-x 2 root root 80 Dec 23 16:49 .ssh
You're confusing a few things.
Rescue Mode boots into its own Linux distro. Don't look at those files - you want to mount YOUR disk, cd into that directory, and look at those files from your disk.
Secondly, to ssh into rescue mode you first need to set root's password then start ssh. Or you can skip all of this and use the webconsole or the lish console.
HTH,
-Chris
How do I mount my disk?
Here is what I did but did not work
root@finnix:/usr# cd ../
root@finnix:/# sudo mount /dev/sdb /dev/sda
mount: /dev/sda: unknown filesystem type 'swap'.
32 root@finnix:/#
When booting into Rescue Mode, you can select what disks are attached. You want to attach your data disk, not your swap disk. For example:
-Chris
Ok that is what I have but when I run this command i dont think it works.
root@finnix:/# sudo mount /dev/sda
mount: /dev/sda: can't find in /etc/fstab.
1 root@finnix:/#
Ok that is what I have but when I run this command i dont think it works.
root@finnix:/# sudo mount /dev/sda
mount: /dev/sda: can't find in /etc/fstab.
1 root@finnix:/#
Ok got it to mount I had to create a directory and then mount the disk into that directory
SSHD:
GNU nano 4.9.3 sshd_config
-- $OpenBSD: sshd_config,v 1.103 2018/04/09 20:41:22 tj Exp $
-- This is the sshd server system-wide configuration file. See
-- sshd_config(5) for more information.
-- This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin
-- 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.
Include /etc/ssh/sshd_config.d/*.conf
--Port 22
--AddressFamily any
--ListenAddress 0.0.0.0
--ListenAddress ::
--HostKey /etc/ssh/ssh_host_rsa_key
--HostKey /etc/ssh/ssh_host_ecdsa_key
--HostKey /etc/ssh/ssh_host_ed25519_key
-- Ciphers and keying
--RekeyLimit default none
-- Logging
--SyslogFacility AUTH
--LogLevel INFO
-- Authentication:
--LoginGraceTime 2m
PermitRootLogin yes
--StrictModes yes
--MaxAuthTries 6
--MaxSessions 10
--PubkeyAuthentication yes
-- Expect .ssh/authorized_keys2 to be disregarded by default in future.
--AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2
--AuthorizedPrincipalsFile none
--AuthorizedKeysCommand none
--AuthorizedKeysCommandUser nobody
-- For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
--HostbasedAuthentication no
-- Change to yes if you don't trust ~/.ssh/known_hosts for
-- 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 yes to enable challenge-response passwords (beware issues with
-- some PAM modules and threads)
ChallengeResponseAuthentication no
-- Kerberos options
--KerberosAuthentication no
--KerberosOrLocalPasswd yes
--KerberosTicketCleanup yes
--KerberosGetAFSToken no
-- GSSAPI options
--GSSAPIAuthentication no
--GSSAPICleanupCredentials yes
--GSSAPIStrictAcceptorCheck yes
--GSSAPIKeyExchange no
-- Set this to 'yes' to enable PAM authentication, account processing,
-- and session processing. If this is enabled, PAM authentication will
-- PAM authentication, then enable this but set PasswordAuthentication
-- and ChallengeResponseAuthentication to 'no'.
UsePAM yes
--AllowAgentForwarding yes
--AllowTcpForwarding yes
--GatewayPorts no
X11Forwarding yes
--X11DisplayOffset 10
--X11UseLocalhost yes
--PermitTTY yes
PrintMotd no
--PrintLastLog yes
--TCPKeepAlive yes
--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
-- Allow client to pass locale environment variables
AcceptEnv LANG LC_*
-- override default of no subsystems
Subsystem sftp /usr/lib/openssh/sftp-server
bash_profile looks fine but just in case I rename it and did another reboot without rescue mode and still same issue
SOVLED
Thanks to Josh here is the solution that fixed it for me. root had root:x:0:0:root:/root:/bin/bash without the "/bash".
I would reboot into Rescue mode, mount your disk. and navigate to your disk's /etc/passwd and see if the shell you are loading into to correct. To try and save some back and forth for you I've included the commands needed to mount the disk from the Rescue Guide here:
Create a new directory for your disk:
mkdir -p /media/sda
Mount the disk to make its contents available at the /media/sda directory:
mount -o barrier=0 /dev/sda /media/sda
View the contents of the disk to confirm you can access them:
ls /media/sda
You can now read and write to files on the mounted disk.
From here to access the passwd file you would need to edit /media/sda/etc/passwd (I've used nano but you could use vim, what ever is comfortable for you).
nano /media/sda/etc/passwd
Look for a line that looks similiar to this:
root:x:0:0:root:/root:/bin/bash
and make sure that bin/bash appears. Save out any edits, if you made any, exit out and then reboot your Linode.