ssh public key error

[carepack]

Hi all there,

I'm new to here. So hi everybody. I have hopefully a small problem. Following happened. I wanted to activate squid also for ssl. Following the opnsense guid I created the ca, created the cert and imported it on my client machine. In the end in my fast and hurry action it didn't work and I decided to move on when more time is present. I deleted the CA for fw. The result is that I'm not longer able to ssh into my fw. Neither with root or additional users. Thats the verbose output from my ssh client:

Code: [Select]

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
debug3: start over, passed a different list publickey
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: Offering RSA public key: /home/micha/.ssh/id_rsa
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey
debug1: Trying private key: /home/micha/.ssh/id_dsa
debug3: no such identity: /home/micha/.ssh/id_dsa: No such file or directory
debug1: Trying private key: /home/micha/.ssh/id_ecdsa
debug3: no such identity: /home/micha/.ssh/id_ecdsa: No such file or directory
debug1: Trying private key: /home/micha/.ssh/id_ed25519
debug3: no such identity: /home/micha/.ssh/id_ed25519: No such file or directory
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey).
I hope the community is able to help. I want to avoid to resetup the whole system. Thank you all

[fabian]

What does the system log of OPNsense contain?

Are there any issues with the code (Bugs)?

Are the public keys still present in your configuration?

If you have shell access without ssh, does .ssh/authorized_keys contain your public key?

This files require special file permissions - what is the output of "ls -la" in this directory and in your home directory?

[carepack]

so, system logs of pfsense

Code: [Select]

May 11 11:55:44 lighttpd[75436]: (connections.c.1550) SSL: 1 -1 error:140E0197:SSL routines:SSL_shutdown:shutdown while in init
May 11 11:55:44 lighttpd[75436]: (connections.c.1550) SSL: 1 -1 error:140E0197:SSL routines:SSL_shutdown:shutdown while in init
May 11 11:55:44 lighttpd[75436]: (connections.c.1550) SSL: 1 -1 error:140E0197:SSL routines:SSL_shutdown:shutdown while in init
May 11 11:55:44 lighttpd[75436]: (connections.c.1550) SSL: 1 -1 error:140E0197:SSL routines:SSL_shutdown:shutdown while in init
May 11 11:55:44 lighttpd[75436]: (connections.c.1550) SSL: 1 -1 error:140E0197:SSL routines:SSL_shutdown:shutdown while in init
May 11 11:55:44 lighttpd[75436]: (connections.c.1550) SSL: 1 -1 error:140E0197:SSL routines:SSL_shutdown:shutdown while in init
May 11 11:55:44 lighttpd[75436]: (connections.c.1550) SSL: 1 -1 error:140E0197:SSL routines:SSL_shutdown:shutdown while in init
May 11 11:55:44 lighttpd[75436]: (connections.c.1550) SSL: 1 -1 error:140E0197:SSL routines:SSL_shutdown:shutdown while in init
May 11 11:55:44 lighttpd[75436]: (connections.c.1550) SSL: 1 -1 error:140E0197:SSL routines:SSL_shutdown:shutdown while in init
May 11 11:55:44 lighttpd[75436]: (connections.c.1550) SSL: 1 -1 error:140E0197:SSL routines:SSL_shutdown:shutdown while in init
May 11 11:54:54 lighttpd[75436]: (connections.c.1550) SSL: 1 -1 error:140E0197:SSL routines:SSL_shutdown:shutdown while in init
May 11 11:54:48
The file requires 0600. The thing is, I dont want a certiface authentication. I will go back to normal password query. I think opn got some problems with removing the authority.

thats grabbed from the system logs of opn also when I try to sign in:

Code: [Select]

May 11 11:59:49 sshd[51833]: Disconnected from 192.168.179.32 port 38230
May 11 11:59:49 sshd[51833]: Received disconnect from 192.168.179.32 port 38230:11: disconnected by user
May 11 11:59:49 sshd[51272]: Accepted keyboard-interactive/pam for admin from 192.168.179.32 port 38230 ssh2
May 11 11:59:40 sshd[50762]: Connection closed by 192.168.179.32 port 38222 [preauth]

[carepack]

ok. I'm one step further. I'm able to login via ssh again with the root user. but with every other user(existing, new, recreated) I can't. The error message is:

Code: [Select]

FreeBSD 10.2-RELEASE-p14 (SMP) #0 1b3679a(stable/16.1): Mon Apr  4 15:36:45 CEST 2016

Welcome to FreeBSD!

Release Notes, Errata: https://www.FreeBSD.org/releases/
Security Advisories:   https://www.FreeBSD.org/security/
FreeBSD Handbook:      https://www.FreeBSD.org/handbook/
FreeBSD FAQ:           https://www.FreeBSD.org/faq/
Questions List: https://lists.FreeBSD.org/mailman/listinfo/freebsd-questions/
FreeBSD Forums:        https://forums.FreeBSD.org/

Documents installed with the system are in the /usr/local/share/doc/freebsd/
directory, or can be installed later with:  pkg install en-freebsd-doc
For other languages, replace "en" with a language code like de or fr.

Show the version of FreeBSD installed:  freebsd-version ; uname -a
Please include that output and any error messages when posting questions.
Introduction to manual pages:  man man
FreeBSD directory layout:      man hier

Edit /etc/motd to change this login announcement.
This account is currently not available.
Connection to ofw closed.

Is there any switch to enable ssh again. The test users are all in the admin group btw.

[carepack]

ok. solved. ssh in via root and execute the following:

chsh -s /usr/local/etc/rc.initial username

to define the shell for the user. should work! seems that the shell is not longer added to a new user

[carepack]

unfortunately, it's not solved. After next reboot the problem is there again

[fabian]

You need to add the permission to log in to the user.

[franco]

Removing a CA can have no impact on SSH, it's a different subsystem.

The shell permission privilege is likely missing from the user.