Problem with ssh to log in


I used an ssh key (pub.key) since a while with a passphrase. I have a config in .ssh

Host router
    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?

 ssh router
root@'s password: 
Permission denied, please try again.
root@'s password: 
Permission denied, please try again.

EDIT: finaly I changed the port, 22 to 1400, and it is working, WHY????

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?

Update? New package?

1 Like


No i just picked up another port (random) to try, just to see and it worked.

Ive installed package: openssh-sftp-server 3 days ago but my ssh sessions worked well

Presumably the dropbear ssh server is still running on port 22. That probably has a different password.

By changing your openssh server to port 1400, you avoided the occupied port, and thus the openssh @ port 1400 was available for login.


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?

Ive just installed it that to use filezilla to access my open wrt files and folders more easily vs ssh.. And it worked.

And Putty or my fav WinSCP

If you like what you have and the mystery is solved. Live long and prosper!

1 Like

Yes winscp is great but with linux (wine) i have some bugs

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.

1 Like

thank you, but still don't understand everything worked well during 2 days on port 22 with openssh sftp server and now not.

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.

1 Like

Fun facts and now some cool tools

/etc/init.d$ /etc/init.d/dropbear status
/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