Hello, everyone!
A Linux-background person here who got a job with an organization that has a few FreeBSD machines.
I was given SSH access to one of them. It used password authentication. Fast forward a couple of months, and today I added two packages: `pkg install bash` and `pkg install mc-nox11`.
Next, I ran `chsh -s /usr/local/bin/bash` to get the shell that `mc` likes, did some work in `mc`, and ran `chsh -s /sbin/sh`.
Once this was done, I could no longer log in through SSH. It displayed 'Closed connection by <IP address> port 22'.
Having checked everything: that OpenSSH was enabled and up, that the port was still open on the firewall, that password auth was still enabled, etc, I ran `ssh -vvv` and found that it establishes the connection, negotiates the ciphers/keys, and bails out. I switched each of the above items off, rebooted the box, switched them back on, but no dice.
After all, I fixed this by `ssh-copy-id <user>@<IP address>` which placed my cert on the server, and then I could connect again.
Hence the question: what have I done, and can that be reverted?
If this is a difficult question, which requires an investigation, we don't absolutely need to spend the effort, but if this is something simple that everyone (except me, obviously) knows off the top of their heads, then why not revert this system back to the state before I messed with it?
Thank you for your help!
A Linux-background person here who got a job with an organization that has a few FreeBSD machines.
I was given SSH access to one of them. It used password authentication. Fast forward a couple of months, and today I added two packages: `pkg install bash` and `pkg install mc-nox11`.
Next, I ran `chsh -s /usr/local/bin/bash` to get the shell that `mc` likes, did some work in `mc`, and ran `chsh -s /sbin/sh`.
Once this was done, I could no longer log in through SSH. It displayed 'Closed connection by <IP address> port 22'.
Having checked everything: that OpenSSH was enabled and up, that the port was still open on the firewall, that password auth was still enabled, etc, I ran `ssh -vvv` and found that it establishes the connection, negotiates the ciphers/keys, and bails out. I switched each of the above items off, rebooted the box, switched them back on, but no dice.
After all, I fixed this by `ssh-copy-id <user>@<IP address>` which placed my cert on the server, and then I could connect again.
Hence the question: what have I done, and can that be reverted?
If this is a difficult question, which requires an investigation, we don't absolutely need to spend the effort, but if this is something simple that everyone (except me, obviously) knows off the top of their heads, then why not revert this system back to the state before I messed with it?
Thank you for your help!
