I used an ssh key (pub.key) since a while with a passphrase. I have a config in .ssh
like
Host router
HostName 192.168.1.1
Port 22
User root
IdentityFile ~/.ssh/id_ed25519
PubkeyAcceptedKeyTypes +ssh-rsa
AddKeysToAgent yes
Never had a single issue with that, I always type : ssh router and add my passphrase and thats it.
But after a reboot, it asks me a password and even my password does not work, I removed my ssh key and check the passsword boxes in system-admin and it does not work, really dont know what happened?
Refresh my memory, because I don't remember setting this up..
Why or what made you think to use 1400 as a guess from the default port 22?
I get this sounds crass but maybe you'll remember some clue about this odd port assignment.
Reading over this once again, it seems you reconfigured this ssh paraphrase to work, but could not get it back on port 22. So you arbitrarily choose port 1400?
Primary question is why if failed in the first place and secondarily why you can't put it on Port 22?
Ok, so what now occurs if you try to reinvent the ssh paraphrase on port 22?
and what occurs if you uninstall the new package and reinvent the ssh paraphrase on port 22?
Does the openssh-sftp-sever have a config that replaced the port or can be assigned a port?
So I think we've figured out the reason it wasn't working... dropbear ssh still running (with a different password than your openssh server) on port 22 caused a conflict with openssh server which was also trying to use the same port. Once you moved openssh to port 1400, it was able to run and accept connections.
You can:
disable dropbear and move openssh back to port 22
change the port for dropbear to somethign else and use openssh on port 22
stick with openssh on a different port (1400 in this case).
If your problem is solved, please consider marking this topic as [Solved]. See How to mark a topic as [Solved] for a short how-to.
Here's my theory... you stopped the dropbear service but did not disable it. When you rebooted, dropbear started up because it was still enabled as a startup item. Dropbear launched before openssh started, and thus the conflict.
/etc/init.d$ /etc/init.d/dropbear status
running
/etc/init.d$ /etc/init.d/dropbear
Syntax: /etc/init.d/dropbear [command]
Available commands:
start Start the service
stop Stop the service
restart Restart the service
reload Reload configuration files (or restart if service does not implement reload)
enable Enable service autostart
disable Disable service autostart
enabled Check if service is started on boot
killclients Kill dropbear processes except servers and yourself
running Check if service is running
status Service status
trace Start with syscall trace
info Dump procd service info
Bit late now but at lease you know what to run against anything in the /etc/init.d/ folder