You are not logged in.
I am very new to ssh and as an experiment I'm trying to use my Arch laptop to ssh-connect to my Arch desktop.
In my laptop when I run user@server-address I get the error:
Permission denied (publickey)As this is just a trial, I'm trying to connect without using key-gen and solely using the user's password.
In the host, I mainly changed a couple of things in /etc/sshd_config:
PasswordAuthentication yes
AllowUsers lenovo
#AllowAgentForwarding yes
AllowTcpForwarding yes
#GatewayPorts no
X11Forwarding yes
X11DisplayOffset 10
X11UseLocalhost yesEverything else in that file is default.
Question is, is it possible to ssh without using key-gen? How does one do it?
Last edited by d_fajardo (2019-09-02 21:34:56)
Offline
Add -vvv for more informed debugging info.
Offline
In my laptop when I run user@server-address I get the error:
Permission denied (publickey)...
... AllowUsers lenovo
Thus, "user" is not allowed to connect, only "lenovo".
Inofficial first vice president of the Rust Evangelism Strike Force
Offline
Thus, "user" is not allowed to connect, only "lenovo".
Sorry to be vague but it was actually brightchip@server-address. I need clarification on this. Is AllowUser the user from the client side who is trying to connect or the user of the host I'm trying to connect to?
Offline
This is the verbose output from client side:
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/lenovo/.ssh/id_rsa
debug1: Trying private key: /home/lenovo/.ssh/id_dsa
debug1: Trying private key: /home/lenovo/.ssh/id_ecdsa
debug1: Trying private key: /home/lenovo/.ssh/id_ed25519
debug1: Trying private key: /home/lenovo/.ssh/id_xmss
debug2: we did not send a packet, disable method
debug1: Next authentication method: password
brightchip@192.168.0.68's password:
debug2: we sent a password packet, wait for reply
debug1: Authentications that can continue: publickey,password
Permission denied, please try again.
brightchip@192.168.0.68's password:
debug2: we sent a password packet, wait for reply
debug1: Authentications that can continue: publickey,password
Permission denied, please try again.
brightchip@192.168.0.68's password:
debug2: we sent a password packet, wait for reply
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
brightchip@192.168.0.68: Permission denied (publickey).Offline
The server is only aware of the username sent to it not what username a user on anther system may actually be and it is only checking for the username / host to allow.
This will be the username the client will be connected to the server as.
AllowUsers
This keyword can be followed by a list of user name patterns,
separated by spaces. If specified, login is allowed only for
user names that match one of the patterns. Only user names are
valid; a numerical user ID is not recognized. By default, login
is allowed for all users. If the pattern takes the form
USER@HOST then USER and HOST are separately checked, restricting
logins to particular users from particular hosts. HOST criteria
may additionally contain addresses to match in CIDR ad‐
dress/masklen format.
Offline
This will be the username the client will be connected to the server as.
From what I did in my script, it looks like my understanding is correct.
Offline
The user lenovo does exist on the server can login?
Check the server log if needed increase the LogLevel in sshd_config.
Last edited by loqs (2019-09-02 19:58:24)
Offline
No it seems I still misunderstood. lenovo does not exist in the server. I will try something out and check the server log.
Offline
Sorry to be vague but it was actually brightchip@server-address.
And is 'brightchip' a user account on the server? If so, then the config should be "AllowUsers brightchip".
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
I disabled AllowUser and was able to login. It seems it's been the culprit all along. I tried both lenovo, which is the client side, and brightchip, which is the server side, as AllowUser names but won't connect so I'm still foggy on this field in the script.
I'll mark this thread as solved as this issue is resolved but I'll continue to experiment with ssh including key-gen, etc. Thanks all for your help.
EDIT: Yes brightchip is the only user in the server.
Last edited by d_fajardo (2019-09-02 20:28:58)
Offline
Did you restart the ssh server after altering the config?
Online
No. It was too early to throw in the towel. I exited and tried to login again and I'm getting the same error.
So I was able to login. Also note that I've configured to have a static ip address so finding the address shouldn't be a problem.
I'll make this change: AllowUsers brightchip and restart the server and post the logs.
Offline
I'm confused, you said you changed the config and were able to log in, but you didn't restart the server. If these are true statements, changing the config did not result in the successful log in. But how did you log in? What was different? You have sentences back to back saying you got the same error, then you were able to login. Which is it? What is actually happening.
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
Sorry about the confusion. Personal error. This time around I did things mindfully. Change the config with AllowUsers brightchip and restarted the server including the client.
And yes I can connect. I will test this further and see if it remains stable.
Last edited by d_fajardo (2019-09-02 21:26:57)
Offline
Could the IP addressing have a bearing on this?
That would be a completely different error message; and I don't see any of those here.
Offline
EDIT: nevermind all the below as it's irrelevant after an edit-rewrite of a previous post.
You've still not shown any actual commands and output. So saying "it" is a bit temperamental and unpredictable is a bit of the pot calling the kettle black! ![]()
Which machines have a static address? The server will certainly need a static address ... otherwise you'll have to double check it's address before every attempt to shell into it. The client doesn't really matter, as long as it has access to the server (on the same LAN if this is LAN-only, and not blocked by any firewalls). I'm not sure what you mean by configuring the router statically ... many router configs could matter, but whether or not it has a static address on some network that you are not using certainly isn't relevant.
So tell us more about what you are actually doing: is this all within a LAN: e.g., are the client and server on the same local network behind the same router? Are you shelling into a named server, or are you using the IP address directly? Are you using the local network address, or a global (internet) address? If you are using a server name, what name server provides the IP lookup?
EDIT: while JWR is correct above, failure to find the name/IP used would give a different error, as you've been slow to provide actual commands and output, we can't be 100% certain that you actually are getting the exact same error on each failure. Also, if there are other servers on the same network with running an sshd (even the router may be) then using the wrong address could still result in the reported error due to attempting to connect to the wrong server.
Last edited by Trilby (2019-09-02 21:35:09)
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
Yes I tried to connect and exit a few times and I don't encounter any more problems. As a conclusion, It was my erroneous understanding that the AlllowUser was the user from the client side and now I can see why that can't really be the case. I'll experiment further with ssh like trying to use a key-gen but for now I can mark this as solved. Thanks all!
Edit: Thanks Trilby. Got your message late. My brain is just slowly fading but I did understand everything you said. Sorry for the confusion.
Last edited by d_fajardo (2019-09-02 21:34:19)
Offline