unable to ssh to device after JHF upgrade

[LostBoY]

i recently upgraded my R81.20 Cluster to the latest JHF. however, post upgrade when i try to ssh the device via any user i  get an error "No supported authentication methods available (server sent public key)". I am suspecting the JHF changed something in the sshd_config or templ files..i tried to change the PasswordAuthentication variable to yes from no..after that i didnt get the "No supported authentication." error but the credentials somehow doesnt work.

any help in resolving this is appreciated.

thanks

[AkosBakos]

Hi @LostBoY 

Did you revert the settings?

I checked in my LAB, my cipher settings are this:

[Expert@gw-sakos-lab01:0]# clish -c "show configuration" | grep cipher
set ssh server cipher 3des-cbc off
set ssh server cipher aes128-cbc off
set ssh server cipher aes128-ctr on
set ssh server cipher aes128-gcm@openssh.com on
set ssh server cipher aes192-cbc off
set ssh server cipher aes192-ctr on
set ssh server cipher aes256-cbc off
set ssh server cipher aes256-ctr on
set ssh server cipher aes256-gcm@openssh.com on
set ssh server cipher chacha20-poly1305@openssh.com on
set ssh server cipher rijndael-cbc@lysator.liu.se off
[Expert@gw-sakos-lab01:0]#

These are the default, I did't change them.

What kind of ssh client is in use?

Akos

[the_rock]

Here is how you fix this problem. Funny enough, had customer yesterday with exact same issue. What you do is below ( no need to reboot or cpstop; cpstart after)

1) console into the device 

2) cd /etc/ssh

3) vi sshd_config

4) search for PasswordAuth

5) change all entries to yes

6) :wq! to save

Edit...after reading your post again, sounds like you already tried this, though I would make sure all entried with PasswordAuth do show as yes.

7) test and Im positive it will work

Andy

[Duane_Toler]

I had the exact same phenomenon you described after a recent JHF update.  If you've ever made a custom configuration to the sshd template (like I have), then this will break.   R&D introduced a change that has an error in their xlate script because it inserts a block of text using 'sed'.  I have a TAC case opened for it, and R&D has a task opened and they're working on it now.  They have a potential fix that is being tested.

In the meantime, you need to use cprid on the management server to hack your way through it via rexec to the gateway.  You can also use Gaia API (Ansible or manually) to upload a default sshd_config file to the host.  You can either use cprid or Gaia API run-script to move the file into place (/etc/ssh) and restart SSHD.

It's not pretty, but it's your only option when the gateway is 10,000 mi (or km) away.

(Edit: clarity on what file to upload)

[the_rock]

O wow...so sounds @Duane_Toler when console access is not available, not too many other options : - (

Andy

[Duane_Toler]

Yep, the CPRID hack via SIC is your only remaining option.  You'll have to adapt sk106490 for the commands you need.  This should get you very close:

Assuming you get a clean SSH configuration uploaded via Gaia API put-file, you can move it into place (assuming you uploaded the file to /home/admin):

$CPDIR/bin/cprid_util -server <IP_address_of_Security_Gateway> -verbose rexec -rcmd "mv /home/admin/sshd_config /etc/ssh"

Restart SSHD (Gaia still uses the SysV style scripts, not systemd):

$CPDIR/bin/cprid_util -server <IP_address_of_Security_Gateway> -verbose rexec -rcmd "service sshd restart"

Gaia API is on by default and open to the 'admin' user.  You can use the Ansible module for it, or craft your own method manually.  You can't use SCP or SFTP because SSH is broken.

(Edit: typo)

[the_rock]

I will definitely save this process if I ever come into this situation (sure hope not)

Tx Duane!

Andy