Hot answers tagged ssh
The ssh-keygen(1) man page says for the -F hostname option: Search for the specified hostname in a known_hosts file, listing any occurrences found. This option is useful to find hashed host names or addresses and may also be used in conjunction with the -H option to print found keys in a hashed format. This seems to be what you want.
First step is to generate a private-public key pair on the machine you copy from: ssh-keygen You can go with the defaults, and make sure you don't provide a password for usage. This can take a bit of time. Second step, after the key generation has finished, is to copy the public key to the server using: ssh-copy-id username@server with the appropriate ...
SSHd does not ban IP addresses. Whenever it encounters an authentication failure, it adds an entry to its log, and keeps going. Other pieces of software, however, may read these logs afterwards and ban IPs according to their rules. The most common daemon used for such a task is fail2ban. Fail2ban works with jails. Each jail is associated to a service, a log ...
The X application needs a screen to connect to and normally (if you connect via ssh using -X that is your local screen). What you can do instead is use Xvnc and create a virtual screen for you X application to connect to and then, after logging back in, use a vncviewer to observe what is happening on this virtual screen. This functions in a similar way as ...
You don't need to install Expect on the server. Write an Expect script instead of running expect from a shell script. Have the Expect script itself spawn the SSH client, connect to the server and then loop through the numbers. To save yourself some effort you can record a session where you log in to the server and try some number with autoexpect. Save the ...
You probably need to add a nohup to your startup scripts. It sounds like your processes are terminating when your session ends. You might also want to look at how standard daemons are started with ubuntu, and rewrite the init script your script is referencing.
There is sslh. It can multiplex the connections depending on what type of client is asking. So if a webbrowser comes along it will forward it to nginx and if a ssh client tries to connect forward it to the sshd. The README.md will hook you up with a nice explanation on how it has to be configured.
Changing the login shell does not necessarily prevent users from authenticating (except in some services that check if the user's shell is mentioned in /etc/shells). People may still be able to authenticate to the various services that your system provides to unix users, and may still be authorized to perform some actions albeit probably not run arbitrary ...
You can use chsh command: ~# chsh myuser Enter new shell details when requested: Login Shell [/bin/sh]: /bin/nologin Or shorter version: ~# chsh myuser -s /bin/nologin
Only top voted, non community-wiki answers of a minimum length are eligible