Cannot SSH login using public key
-
Hello all,
I am using the latest version of the community edition, 2.7.0, on a cloud VM.
I am currently just setting it up and I tried to setup SSH access for the default admin user.
Access to it using simply this account's password works fine.When using both BitVise and Putty as SSH clients, using two different key-pairs I create for each of these apps separately, both based on RSA and key size of 4096 - when trying to SSH login using it, I get an error of "The key has been rejected", and pfSense installation becomes unresponsive, at least because the web admin and SSH ports are not responding anymore (ping strangely still works), so I have to reboot the VM.
Yes, I have place the public key content in the admin users public key UI object, and the matching private key in the SSH client with its matching passphrase.
This happens if I use either advanced pfSense SSH options of only public key or public key plus password.
What can I do? (I prefer to use a public key over simply the password)
Also, I didn't find any public article stating which attributes for key pairs for SSH public key access are supported - which algorithms and their size, I will be happy if anyone can refer me to something like this.
Thank you!
-
@Wolfgangthegreat not sure what your trying to do - but it sounds like your not using the gui..
If you want user X to use a public key - use the gui to do that..
Here I just created a test user, pasted in its key.. Told ssh to use that and bobs your uncle
-
@johnpoz I used the GUI all the way...
I used the field for the public key your added to your post.
What were the attributes of the key pair you created / using? which algorithm and key size?
-
@Wolfgangthegreat shouldn't matter.. That was just some old rsa I had laying around..
Just created a rsa 4096 and same clicky clicky works
I use ed25519 for my normal access into pfsense - this was just some test account I created to test your setup.
Just did this on my 2.7 vm in like 10 seconds..
-
@johnpoz Thanks for checking and that it works on your end. It still not working on my side.
Can you direct me about how to get a debug log for the ssh auth? -
@johnpoz , OK, advanced.
Connected using password, opened the freebsd shell, cat /var/log/auth.log and there, for the rejected key access:
pfSense sshguard ... Attack from "x.x.x.x" on service SSH with danger 10.
Blocking "x.x.x.x/32" for 240 secs (3 attacks in 1530 secs, after 2 abuses over 1958 secs.)Now I need to find why it thinks I attack it
-
@Wolfgangthegreat said in Cannot SSH login using public key:
Now I need to find why it thinks I attack it
Because you are attacking it
pfSense (sshgaurd) has no access to your brain to check what your real intentions are.
It does what it is told to do.
You triggered the protection mechanism.No big deal actually. It's time that you show your pfSense who the boss is here.
Netgate created especially for you this page : System > Advanced > Admin Access - you already use it to set up SSH key access : the "Secure Shell" section.
Just below, the very related : "Login Protection".
In that section, you'll find (these are my settings) :
What I did : I excluded the entire LAN (192.168.1.1/24) and my remote VPN access (192.168.3.1/24) as these are trusted networks.
My non trusted devices (users) are on other networks.Btw : when all is ok, go for :
password access will still be granted when using the GUI, but, with some firewall rules, you can limit the GUI access to a network, or just one IP if needed.
-
-
@Wolfgangthegreat no just a fan.. If you fail to auth via ssh no matter the method password or key it would be considered an attack ;)
-
@Wolfgangthegreat said in Cannot SSH login using public key:
get a debug log for the ssh auth?
First thing I would do would be to log your login from your client.. example
[LOCAL] : Attempt connection to session "Local\Infrastructure\sg4860.local.lan (1)" [LOCAL] : SSH2Core version 9.4.1.3102 [LOCAL] : Connecting to 192.168.9.34:22 ... [LOCAL] : Changing state from STATE_NOT_CONNECTED to STATE_EXPECT_KEX_INIT [LOCAL] : Using protocol SSH2 [LOCAL] : RECV : Remote Identifier = 'SSH-2.0-OpenSSH_9.3' [LOCAL] : CAP : Remote can re-key [LOCAL] : CAP : Remote sends language in password change requests [LOCAL] : CAP : Remote sends algorithm name in PK_OK packets [LOCAL] : CAP : Remote sends algorithm name in public key packets [LOCAL] : CAP : Remote sends algorithm name in signatures [LOCAL] : CAP : Remote sends error text in open failure packets [LOCAL] : CAP : Remote sends name in service accept packets [LOCAL] : CAP : Remote includes port number in x11 open packets [LOCAL] : CAP : Remote uses 160 bit keys for SHA1 MAC [LOCAL] : CAP : Remote supports new diffie-hellman group exchange messages [LOCAL] : CAP : Remote correctly handles unknown SFTP extensions [LOCAL] : CAP : Remote correctly sends UTF8 where UTF8 is specified [LOCAL] : CAP : Remote correctly encodes OID for gssapi [LOCAL] : CAP : Remote correctly uses connected addresses in forwarded-tcpip requests [LOCAL] : CAP : Remote is IETF-DRAFT compliant [LOCAL] : CAP : Remote can do SFTP version 4 [LOCAL] : CAP : Remote uses SHA1 hash in RSA signatures for x.509v3 [LOCAL] : CAP : Remote x.509v3 uses ASN.1 encoding for DSA signatures [LOCAL] : CAP : Remote correctly handles zlib@openssh.com [LOCAL] : SEND : KEXINIT [LOCAL] : RECV : Read kexinit [LOCAL] : Available Local Kex Methods = curve25519-sha256@libssh.org,curve25519-sha256,ext-info-c [LOCAL] : Available Remote Kex Methods = curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256 [LOCAL] : Selected Kex Method = curve25519-sha256@libssh.org [LOCAL] : Available Local Host Key Algos = rsa-sha2-512,rsa-sha2-256,ssh-rsa,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,x509v3-rsa2048-sha256,x509v3-ssh-rsa,x509v3-sign-rsa,x509v3-ssh-dss,x509v3-sign-dss,x509v3-ecdsa-sha2-nistp256,x509v3-ecdsa-sha2-nistp384,x509v3-ecdsa-sha2-nistp521,ssh-dss [LOCAL] : Available Remote Host Key Algos = rsa-sha2-512,rsa-sha2-256,ssh-ed25519 [LOCAL] : Selected Host Key Algo = rsa-sha2-512 [LOCAL] : Available Local Send Ciphers = chacha20-poly1305@openssh.com [LOCAL] : Available Remote Send Ciphers = chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr [LOCAL] : Selected Send Cipher = chacha20-poly1305@openssh.com [LOCAL] : Available Local Recv Ciphers = chacha20-poly1305@openssh.com [LOCAL] : Available Remote Recv Ciphers = chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr [LOCAL] : Selected Recv Cipher = chacha20-poly1305@openssh.com [LOCAL] : Available Local Send Macs = hmac-sha2-512,hmac-sha2-256 [LOCAL] : Available Remote Send Macs = hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com [LOCAL] : Selected Send Mac = poly1305 [LOCAL] : Available Local Recv Macs = hmac-sha2-512,hmac-sha2-256 [LOCAL] : Available Remote Recv Macs = hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com [LOCAL] : Selected Recv Mac = poly1305 [LOCAL] : Available Local Compressors = none [LOCAL] : Available Remote Compressors = none,zlib@openssh.com [LOCAL] : Selected Compressor = none [LOCAL] : Available Local Decompressors = none [LOCAL] : Available Remote Decompressors = none,zlib@openssh.com [LOCAL] : Selected Decompressor = none [LOCAL] : Changing state from STATE_EXPECT_KEX_INIT to STATE_KEY_EXCHANGE [LOCAL] : SEND : SSH_MSG_KEX_ECDH_INIT [LOCAL] : RECV : SSH_MSG_KEX_ECDH_REPLY [LOCAL] : Changing state from STATE_KEY_EXCHANGE to STATE_READY_FOR_NEW_KEYS [LOCAL] : RECV: Remote Hostkey ssh-rsa 4096 (SHA-2 hash hex): 04:c4:d5:2c:1e:b2:d3:7e:b1:d8:a7:f8:11:06:51:9d:21:eb:fd:54:84:e0:1a:c4:6d:74:fa:8c:cb:fa:f6:53 [LOCAL] : RECV: Remote Hostkey ssh-rsa 4096 (SHA-2 hash base64): BMTVLB6y036x2Kf4EQZRnSHr/VSE4BrEbXT6jMv69lM [LOCAL] : RECV: Remote Hostkey ssh-rsa 4096 (SHA-1 hash): 77:ae:7e:6c:e4:f8:5f:6e:bb:ac:08:15:b1:3d:70:5b:69:4a:ad:1d [LOCAL] : RECV: Remote Hostkey ssh-rsa 4096 (MD5 hash): 65:ae:10:a1:4d:6c:fc:39:c7:09:38:a5:aa:cc:09:b4 [LOCAL] : SEND : NEWKEYS [LOCAL] : Changing state from STATE_READY_FOR_NEW_KEYS to STATE_EXPECT_NEWKEYS [LOCAL] : RECV : NEWKEYS [LOCAL] : Changing state from STATE_EXPECT_NEWKEYS to STATE_CONNECTION [LOCAL] : SEND: SERVICE_REQUEST[ssh-userauth] [LOCAL] : RECV : SSH_MSG_EXT_INFO [LOCAL] : RECV : Extension name = server-sig-algs [LOCAL] : RECV : Extension value = ssh-ed25519,sk-ssh-ed25519@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ecdsa-sha2-nistp256@openssh.com,webauthn-sk-ecdsa-sha2-nistp256@openssh.com,ssh-dss,ssh-rsa,rsa-sha2-256,rsa-sha2-512 [LOCAL] : RECV : Extension name = publickey-hostbound@openssh.com [LOCAL] : RECV : Extension value = 0 [LOCAL] : RECV: SERVICE_ACCEPT[ssh-userauth] -- OK [LOCAL] : SENT : USERAUTH_REQUEST [none] [LOCAL] : Authenticating as user test27 [LOCAL] : RECV : USERAUTH_FAILURE, continuations [publickey,password,keyboard-interactive] [LOCAL] : SENT : USERAUTH_REQUEST [publickey (rsa-sha2-512) - unsigned,fingerprint (SHA-2 base64 hash): 0Qo+mQaqIGv1lR8yDDB48BgzubwRCckhX9F13VIjsWM=] [LOCAL] : SENT : USERAUTH_REQUEST [publickey (rsa-sha2-512) - unsigned,fingerprint (SHA-2 hash): d1:0a:3e:99:06:aa:20:6b:f5:95:1f:32:0c:30:78:f0:18:33:b9:bc:11:09:c9:21:5f:d1:75:dd:52:23:b1:63] [LOCAL] : SENT : USERAUTH_REQUEST [publickey (rsa-sha2-512) - unsigned,fingerprint (SHA-1 hash): 98:f2:78:42:fd:31:88:6f:cf:12:74:cb:81:63:67:bf:a2:7b:ce:c4] [LOCAL] : SENT : USERAUTH_REQUEST [publickey (rsa-sha2-512) - unsigned,fingerprint (MD5 hash): 8f:05:2e:42:38:03:e3:b2:44:9a:94:dd:b2:f9:a0:3b] [LOCAL] : RECV : SSH_MSG_USERAUTH_PK_OK [LOCAL] : SENT : USERAUTH_REQUEST [publickey (rsa-sha2-512) - signed,May 2000 Standard] [LOCAL] : RECV : AUTH_SUCCESS [LOCAL] : SEND[0]: SSH_MSG_CHANNEL_OPEN('session') [FROM REMOTE] : /home/test27/.ssh/authorized_keys:1: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding [FROM REMOTE] : /home/test27/.ssh/authorized_keys:1: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding [LOCAL] : SEND[0]: Pty Request (rows: 48, cols: 154) [LOCAL] : RECV[0]: pty request succeeded [LOCAL] : SEND[0]: shell request [LOCAL] : RECV[0]: shell request [LOCAL] : RECV[0]: shell request succeeded SecureCRT - Version 9.4.1 (x64 build 3102) Serial Number 03-92-015191 [2.7.0-RELEASE][test27@test.mydomain.tld]/home/test27: [LOCAL] : SEND[0]: window-change (rows: 83, cols: 250) [2.7.0-RELEASE][test27@test.mydomain.tld]/home/test27:here is via openssh on my windows box vs securecrt, had to convert the private key to openssh format first
$ ssh -v test27@192.168.9.34 -i /home/budman/.ssh/test1 OpenSSH_9.4p1, OpenSSL 1.1.1v 1 Aug 2023 debug1: Reading configuration data /home/Budman/.ssh/config debug1: Connecting to 192.168.9.34 [192.168.9.34] port 22. debug1: Connection established. debug1: identity file /home/budman/.ssh/test1 type 0 debug1: identity file /home/budman/.ssh/test1-cert type -1 debug1: identity file /home/Budman/.ssh/id_rsa type 0 debug1: identity file /home/Budman/.ssh/id_rsa-cert type -1 debug1: Local version string SSH-2.0-OpenSSH_9.4 debug1: Remote protocol version 2.0, remote software version OpenSSH_9.3 debug1: compat_banner: match: OpenSSH_9.3 pat OpenSSH* compat 0x04000000 debug1: Authenticating to 192.168.9.34:22 as 'test27' debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: algorithm: curve25519-sha256@libssh.org debug1: kex: host key algorithm: ssh-ed25519 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 debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: SSH2_MSG_KEX_ECDH_REPLY received debug1: Server host key: ssh-ed25519 SHA256:iq3NYEvhqkvT+7G/pbVO84GlrfP/HggwYpstef3NB1I debug1: Host '192.168.9.34' is known and matches the ED25519 host key. debug1: Found key in /home/Budman/.ssh/known_hosts:12 debug1: rekey out after 134217728 blocks debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: rekey in after 134217728 blocks debug1: Will attempt key: /home/budman/.ssh/test1 RSA SHA256:0Qo+mQaqIGv1lR8yDDB48BgzubwRCckhX9F13VIjsWM explicit debug1: Will attempt key: /home/Budman/.ssh/id_rsa RSA SHA256:bmvXXbiFlcdEvz9RmgTma4GE3/xTV4Tuo00WFj97oog explicit debug1: SSH2_MSG_EXT_INFO received debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,sk-ssh-ed25519@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ecdsa-sha2-nistp256@openssh. com,webauthn-sk-ecdsa-sha2-nistp256@openssh.com,ssh-dss,ssh-rsa,rsa-sha2-256,rsa-sha2-512> debug1: kex_input_ext_info: publickey-hostbound@openssh.com=<0> debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,password,keyboard-interactive debug1: Next authentication method: publickey debug1: Offering public key: /home/budman/.ssh/test1 RSA SHA256:0Qo+mQaqIGv1lR8yDDB48BgzubwRCckhX9F13VIjsWM explicit debug1: Server accepts key: /home/budman/.ssh/test1 RSA SHA256:0Qo+mQaqIGv1lR8yDDB48BgzubwRCckhX9F13VIjsWM explicit Authenticated to 192.168.9.34 ([192.168.9.34]:22) using "publickey". debug1: channel 0: new session [client-session] (inactive timeout: 0) debug1: Requesting no-more-sessions@openssh.com debug1: Entering interactive session. debug1: pledge: network debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0 debug1: Remote: /home/test27/.ssh/authorized_keys:1: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding debug1: Remote: /home/test27/.ssh/authorized_keys:1: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding debug1: pledge: fork [2.7.0-RELEASE][test27@test.mydomain.tld]/home/test27:You had asked if 4096 rsa, here is info on the key
Budman@I9-WIN C:\tools\openssl-3.1.3-win64 $ openssl rsa -text -noout -in test1 Private-Key: (4096 bit, 2 primes) modulus: 00:b7:3e:bf:32:86:5c:18:63:db:c0:4b:d0:24:08: 87:66:e5:8c:50:b4:69:e2:d5:3c:a7:f1:9a:ec:e2: e3:0b:5d:dc:2a:cf:f7:24:8b:36:08:e4:3c:5b:11: 53:02:25:70:ec:3f:78:37:a3:e8:5b:31:ae:82:4d: 16:d9:31:4f:87:46:76:37:66:9d:08:68:62:44:3c: 50:9d:b4:92:5a:63:4b:fb:c2:57:d5:ae:5c:68:6f: 83:e9:8a:5e:d8:dc:fa:73:b3:f7:a6:d4:05:cb:50: $ ssh-keygen -lf /home/budman/.ssh/test1.pub 4096 SHA256:0Qo+mQaqIGv1lR8yDDB48BgzubwRCckhX9F13VIjsWM test@i9-win.local.lan (RSA)Here you mentioned you were using putty..
Had to convert the key to putty format, but again clickly clicky and in..
Have you read
https://docs.netgate.com/pfsense/en/latest/recipes/ssh-access.html
If your not doing this with admin account, did you give the user the right permissions? From the link above
Additional users with limited access may be granted the User - System - Shell account access privilege to login via SSH. -
OK... I was able to solve it.
After whitelisting my IP I still couldn't login, the auth.log now stated:
Oct 20 06:19:18 pfSense sshd[xxx]: error: Received disconnect from x.x.x.x port 6692:13: User request [preauth]
Oct 20 06:19:18 pfSense sshd[xxx]: Disconnected from authenticating user admin x.x.x.x port 6692 [preauth]The port is I guess the source port of my client session attempt.
So, I went back to check the public key format and I tried now, using now ed25519, and it also didn't work.
But now I noticed that the client application that I use, Bitvise, can export the public key in two formats, SSH2 (which is the default export format of this app, the one I used so far) and OpenSSH.After few tests I found the root cause:
pfSense can use only a public key in OpenSSH format. Using the SSH2 format caused the post-whitelisting issue.I also did another test – I removed my client/source IP from the login protection whitelist of pfSense and then I was also able to login just fine.
Hence, the use of non-OpenSSH format key was interpreted by sshguard as an attack.I think that Negate should:
-
Add at https://docs.netgate.com/pfsense/en/latest/usermanager/users.html, at the SSH Public key section, info about the need to use a correct public key format, of OpenSSH (preferred with a sample key(s) to show folks how it should look like)
-
Add to the user attributes GUI an input text validator mechanism, for the pub key field, to accept only the correct OpenSSH format (I guess it can be done with regex) and warn if it is not in the correct format. And of course, not save the key if it is in the wrong format if the user still presses "save" on that page
*** Sample of OpenSSH format of a public key, the CORRECT format ***
(these are only general format samples, to get a general visual idea, they are not the original content and are not valid for actual use, the content was intentionally changed at these samples):ed25519 based
ssh-ed25519 AAA3CzNzaC1lZDIoqTE5AAAAINYE4MbzehJH1C7RIVVeqw8m5wg5vCC4PDYFjGdbdxfP
RSA based
ssh-rsa AAAAB3NzaC1yc2EAAAADAYABAAACAzCtXvp5xUFTi7pra1wEGxh0/Y40JpkYZE/U8BKhiJyypJR5qJO8uw8ZjNthgGSXPBCAwPFndzN0TzgX7fJONazIUskVK03JQPw/yKqVAMu93AnApCSiywlRjUf2Mcbe/E1qQ3onsbX2uCajNRp63KdSwYZGTslO6xhjWjslDw67/MOOouuNmWr67b6b4FRzBoZU4ZllPU7ChViukayump2FbCEdJxwJjq7q552uILUwjUMi0c3MLIiRXRZIizox2A8tledHe0vcGu7z1a5ofnS0P0LwfVs6C9c7ypQYT3gEGdPWMS2OBABg/vuJ0LCGVr6AJCsX5VFo6kUtWBMgnhoRqlGO8uBPGzHhWY8UeRBLufkljUQPPEapIxViZC2KQjMC2unjnZU3Sqwz9++DpspHdP9+pLwrx7CtFQNIsmmNX4Cwcv6OBqQLXXhnW56v2e6+XezvdpQ8dUgndRH0z2iVAaCbxE3oM6VcMw91uJTpN3jPjVEryi8tZgUTr922dd42lZtf9y0c8DciXOIr7F6zedGepD5S9zc5LjKi1Gu5U7kyM3fr0uACulu1fXscHUQFhaHpf4f3Yz7p+d9QxwUj6EANo9BNsmP00L7vGXP6PpaoXDLdEeunUCO35Zptdke4BjUAxy1HDy+dt1VMoSAYdnFPwCtidqTcNsmBWOaLKQ==
*** Sample of the SSH2 format of a public key, the WRONG format ***
ed25519 based
---- BEGIN SSH2 PUBLIC KEY ----
AAAAC3NzaC1lzDI1NTE5AAAAINYE4MbzehJH1CdRIVVeqw5m8wg5vCC4PDYFjGZbdsfP
---- END SSH2 PUBLIC KEY ----RSA based
---- BEGIN SSH2 PUBLIC KEY ----
AAAAB3NzaC1yc2EAAAADAQABAAACAQCtXvp5xUFTi7pra1wEGxh0/Y40JpkYZE/U8BKhiJyy
pJR3qJO8uw8ZjNthgGSXPBCAwPFndzN0ezgX7fJONazIUskVK03JQPw/yKqVAMu93AnApCSi
ywlRjUf2Mcbe/E1qQ3onsbX2uCajNRp63KdSwYZGTslO6xhjWjslDw67/MOOouuNmWr67b6b
4FRzBoZU4ZllPU7ChViukayump2FbCEdJxwJjq7q552uILUwjUMi0c3MLIiRXRZIizox2A8t
ledHe0gcGu7z1a5ofnS0P0LwfVs6C9c7ypQYTegEGdPWMS2OBABg/vuJ0LCGVr6AJCsX5VFo
6kUtWBMgnhoRqlGO8uBPGzHhWY8UeRBLufkljUQPPEapIxViZC2KQjMC2unjnZU3Sqwz9++D
pspHdP9+pLwrx7CtFQNIsmmNX4Cwcv6OBq/LXXhnW56v2e6+XezvdpQ8dUgndRH0z2iVAaCb
xE3oM6VcMw91uJTpN3jPjVEryi8tZgUTr922dd42lZtf9y0c8DciXOIr7F6zedGepD5S9zc5
LjKi1Gu5U7ByM3fr0uACuluadXscHUQFhaHpf4f3Yz7p+d9QxwUj6EANo9BNsmP00L7vGXP6
PpaoXDLdEgunUCO35Zptdke4BjUAxy1HDy+de1VMoSAYdnFPwCtidqTcNsmBWOaLKQ==
---- END SSH2 PUBLIC KEY ---- -
-
@Wolfgangthegreat said in Cannot SSH login using public key:
info about the need to use a correct public key format
Why would you have thought you could use anything other than openssh format.. Its using openssh as the daemon.. But I agree adding a note to that effect would be good.
Glad you got it sorted..
[2.7.0-RELEASE][test27@test.mydomain.tld]/home/test27: ssh -V OpenSSH_9.3p1, OpenSSL 1.1.1t-freebsd 7 Feb 2023 [2.7.0-RELEASE][test27@test.mydomain.tld]/home/test27: -
@johnpoz Well, not all are Linux and pfSense hard fans... some come with no/different background.
The smart ones should somewhat protect the domain-weak/domain-stupid ones...
Thanks. -
@Wolfgangthegreat maybe I should of asked that question first thing I guess - but it did not dawn on me that you would not be using openssh format.. Sorry. I will for sure know to validate that next user that having an issue.
The good thing that came from it, is its working - and adding a note to both the gui and the doc about correct format for the keys would be good to do. And also if there is some way to do a check when user paste in the key that is not right, would also be good..
They should also have an ability to easy adjust what ciphers, kex and such that are used in the gui.. if normally they keep up with common best practice for what to support, etc that is fine as well. But being able to tweak the ssh stuff, and the webgui algorithms as well would all be good additions.
BTW it wasn't that key was wrong format or anything on why considered an attack, it was just plain jane failure to auth.. Be it your key doesnt work for whatever reason, or you just send the wrong password - failure to auth would be considered for sshguard an "attack". And yeah you can lock yourself out for a time. It is best to put in IP or IP range of IPs that can not be locked out.
-
@johnpoz Thanks.
I went one step ahead an filed a feature request for the things I asked earlier.
It is at https://redmine.pfsense.org/issues/14899
