Initially they are in sync and then when i check hours later, only one of them will be on the current time and the other two will be 30-40 minutes behind. I believe the issue to be with syslog now. I really don't want to build the boxes from scratch again, so i'm hoping it's a simple fix and that someone else has any clue where I can dig to get these ready to go without doing a rebuild Thanks!Įd, thanks for responding again to my thread! A /var/log/secure doesn't exist on ESXiĭSTAVERT, you are correct, ESXi does use UTC, which isn't a problem for me, I have all three hosts syncing with a local NTP server and all hosts have the correct date, when I issue the I"m not sure if there where the settings are for the dropbear ssh logs for logins or if something is a miss. However on my two other servers, whose configs are identical, when I go to duplicate this on their side, the dropbear doesn't appear to be in the /var/log/messages or in one case it was extremely delayed, by hours. #tail -f /var/log/messages | grep dropbearĪnd then I open a new putty session to log in, it will log accordingly and in realtime the attempt of username, or nonexistant username if it doesn't exist, and what IP address it is coming from. I've been trying to create custom rules that are monitoring the remote syslog from each host, I am trying to create a warning that tells me when someone is trying to login to each host via ssh. I have three identical HP Bl490c blades with identical configurations. This is from 2013, so they could have updated.Just about done with my ESXi host buildout for my migration. That states cyberduck does not have a real scp mode and thus fails to connect to dropbear ssh. I also noticed that there is a cyberduck ticket: Where (hostname) is the ip-address or computer name that you are connecting to (which looks to be 192.168.1.1)Īs our friends over in openwrt specified: If the key has changed and you need to fix this in a terminal on your Mac run: It will have to fall back to scp, which is doing an ssh copy, which under the hood opens an ssh session and then does a copy (cp) to the remote/local machine. proftp does not have ssh wrapping so either way you cannot use SFTP to connect to the router or even FTPS (which is FTP but encrypted) This dropbear will not know how to understand the ssh secured ftp protocol. This means that either Cyberduck has removed/deprecated the algorithms that dropbear has enabled or vise versa.Įven if you get this algorithm to agree and the keys exchanged, the DD-WRT version of dropbear does not contain the sftp subsystem. I am not a Mac user but a Linux and BSD user, since is a derivative from FreeBSD, there are similarities.įrom Cyberduck is specifying that between the dropbear on the router and its software, the algorithm for exchanging ssh keys was not agreed upon.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. Archives
January 2023
Categories |