1
# ssh -l admin 10.1.0.2
Warning: Permanently added '10.1.0.2' (RSA) to the list of known hosts.
root@10.1.0.2's password: 

Using "OpenSSH_8.4p1 Debian-5+deb11u1, OpenSSL 1.1.1n" I want to connect to a remote host, but what ever I try, it always reverts the login to root. Configuration files has been renamed to ensure that no User option is being applied. The only hint I get is this line:

debug1: Authenticating to 10.1.0.2:22 as 'root'

-- EDIT --

To provide more information, here is a debug output up to the point where SSH decides to authenticate as root, though told not to do so.

xxxxxxx:~$ ssh -vvv -p4711 foo@xxx.xxx.xxx.xxx
OpenSSH_8.4p1 Debian-5+deb11u1, OpenSSL 1.1.1n  15 Mar 2022
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files
debug2: resolve_canonicalize: hostname xxx.xxx.xxx.xxx is address
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts' -> '/home/xxx/.ssh/known_hosts'
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts2' -> '/home/xxx/.ssh/known_hosts2'
debug2: ssh_connect_direct
debug1: Connecting to xxx.xxx.xxx.xxx [xxx.xxx.xxx.xxx] port 4711.
debug1: Connection established.
debug1: identity file /home/xxx/.ssh/id_rsa type -1
debug1: identity file /home/xxx/.ssh/id_rsa-cert type -1
debug1: identity file /home/xxx/.ssh/id_dsa type -1
debug1: identity file /home/xxx/.ssh/id_dsa-cert type -1
debug1: identity file /home/xxx/.ssh/id_ecdsa type -1
debug1: identity file /home/xxx/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/xxx/.ssh/id_ecdsa_sk type -1
debug1: identity file /home/xxx/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /home/xxx/.ssh/id_ed25519 type -1
debug1: identity file /home/xxx/.ssh/id_ed25519-cert type -1
debug1: identity file /home/xxx/.ssh/id_ed25519_sk type -1
debug1: identity file /home/xxx/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /home/xxx/.ssh/id_xmss type -1
debug1: identity file /home/xxx/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.4p1 Debian-5+deb11u1
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.4p1 Debian-5
debug1: match: OpenSSH_8.4p1 Debian-5 pat OpenSSH* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to xxx.xxx.xxx.xxx:4711 as 'root'
debug3: put_host_port: [xxx.xxx.xxx.xxx]:4711
debug3: hostkeys_foreach: reading file "/home/xxx/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /home/xxx/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys from [xxx.xxx.xxx.xxx]:4711
debug3: order_hostkeyalgs: have matching best-preference key type ecdsa-sha2-nistp256-cert-v01@openssh.com, using HostkeyAlgorithms verbatim

As you can see, there are no configuration file options applied. What puzzles me most is, that on a different host using the same ssh client version, it works. I still think that I'm missing something fundamental. Any ideas?

Thanks.

4
  • That is indeed strange. Typically running the ssh client with -v and/or -vv debug flags will show which configuration files get applied and in what order, for example debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 58: Applying options for ... and debug1: Reading configuration data /Users/diya/.ssh/config - Does that list any particulars?
    – diya
    Nov 10, 2022 at 13:37
  • No. I've renamed the files that has been applied to test this, but it didn't solve the problem.
    – cybin
    Nov 10, 2022 at 13:40
  • Hi, but one configuration file did get applied: debug1: Reading configuration data /etc/ssh/ssh_config - please check its content...
    – Martin
    Nov 11, 2022 at 9:08
  • Usually, SSH says something like debug1: /etc/ssh/ssh_config line 21: Applying options for * if it applies an option. In the output it just reads the file, but doesn't seem to apply anything.
    – cybin
    Nov 11, 2022 at 9:37

1 Answer 1

1

Sorry, for taking your time... I've found the cause of this behaviour:

alias ssh='ssh -l root -o "PreferredAuthentications publickey,password"'

Didn't know, that a package set this alias in /etc/bash.bashrc.

Kind regards...

2
  • Ouch. That's really bad. Which package was responsible for that? Nov 16, 2022 at 12:08
  • Don't worry. It's in one of our companies package, which are not public.
    – cybin
    Nov 17, 2022 at 8:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.