sudo XAUTHORITY=/home/mruckman/.Xauthority gedit &
sudo XAUTHORITY=/home/<user>/.Xauthority gedit &

Technical notes, and other ideas.
sudo XAUTHORITY=/home/mruckman/.Xauthority gedit &
sudo XAUTHORITY=/home/<user>/.Xauthority gedit &
Refer: closed-by-remote
It looks like there are two issues. Use a VPN and also, do not automatically send password, make it a manual step. It looks like GoDaddy blocks it, if it looks automated like a hacking attempt. Basically, type your password in manually.
echo "password"
# DEBUG MODE
### ssh -oConnectTimeout=300 -oHostKeyAlgorithms=+ssh-dss userid@XX.XX.XX.XXX -vvv
# NORMAL MODE
ssh -oConnectTimeout=300 -oHostKeyAlgorithms=+ssh-dss userid@XX.XX.XX.XXX
I keep getting blocked out of ssh-ing to my GoDaddy CPanel hosting account randomly.
At first I am able to ssh into my account and works fine. But randomly I'll get a:
Connection to "GoDaddyIP" closed by remote host.
Connection to "GoDaddyIP" closed.
"GoDaddyIP" = my personal cPanel IP address.
After I get disconnected I am not able to reconnect. If I try it from same computer but different IP address. i.e. I connect to a different internet connection or my cellular hotspot, I am able to connect just fine. I've called support and they were no help. The best they could do is say "Well, I'm able to connect to that account" Of course they can. They are using a different IP. Anyhow, the IP I'm connect through is not in BlockedIP with GoDaddy and everything I've read online is of no help. Does anyone have a solution?
Symptom
sign_and_send_pubkey: signing failed for RSA
Solution, make sure your ~/.ssh/id_rsa has the proper permissions, it should be read/write for the owner and none for anyone else.
Refer: https://forum.snapcraft.io/t/x11-forwarding-using-ssh/2381/2
Solution by: jdstrand
strace was used to find solution:
Refer: https://www.tecmint.com/strace-commands-for-troubleshooting-and-debugging-linux/
Symptom:
$ handbrake-jz.ghb
X11 connection rejected because of wrong authentication.
Here's the fix for Handbrake:
ln -s ~/.Xauthority ~/snap/handbrake-jz/current/.Xauthority
Here's the generic solution:
ln -s ~/.Xauthority ~/snap/
Store your SSH settings in one file
Refer: https://askubuntu.com/questions/727903/how-to-save-ssh-options-and-connections-in-ubuntu
Refer: https://askubuntu.com/questions/87956/can-you-set-passwords-in-ssh-config-to-allow-automatic-login/89126
If you precede with a space it won't show in history
$ sshpass -p password-here ssh server-name-here
You can remove your passphrase
ssh-keygen -p
And then follow the prompts, and keep it blank
protectmyhalaccount4menowandthatsallshewrote
You can use a per-user ssh-config file located in
~/.ssh/config
or a system-global one in
/etc/ssh/ssh_config
Host x_label_to_call_here
User user-name-here
HostName host-name-here-or-ip-address
Port 22
Example for Ubuntu as follows:
$ sshpass -p 'YourPassword' ssh user@host
For 18.04 you will need to install through Synaptic
This simple tutorial is going to show you how to enable Secure Shell (SSH) service in Ubuntu 14.04 Trusty Tahr.
Secure Shell (SSH) is a cryptographic network protocol for secure data communication, remote command-line login, remote command execution, and other secure network services between two networked computers.
SSH is not enabled by default in Ubuntu, but you can easily enable this service via OpenSSH, a free version of the SSH connectivity tools developed by the OpenBSD Project.
To do so, run the command below in terminal:
sudo apt-get install openssh-server
Remove login with root password
$ sudo nano /etc/ssh/sshd_config
# Authentication:
LoginGraceTime 120
PermitRootLogin no
Or install the openssh-server package via Ubuntu Software Center if you’re on Desktop edition:
install ssh server Ubuntu 14.04
Once installed, you can change the port, disable root login and do other changes by editing the config file:
sudo gedit /etc/ssh/sshd_config
Finally restart the ssh server to take place:
sudo /etc/init.d/ssh restart
When doing ssh or scp you get the following error:
no matching cipher found: client aes256-cbc,aes192-cbc,blowfish-cbc,cast128-cbc,aes128-cbc,3des-cbc server chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr
You can fix with, but you've removed security
$ scp -c none other-stuff-here
$ ssh -c none username@hostname
Refer: http://steronius.blogspot.com/2014/10/ssh-no-matching-cipher-found.html
[jboss1@haldevjbs13 /tmp/mongo-backup/export-testcms-20160709]$ less /home/jboss1/.ssh/known_hosts.old
[jboss1@haldevjbs13 /tmp/mongo-backup/export-testcms-20160709]$ less /home/jboss1/.ssh/known_hosts
Official Download: http://sourceforge.net/projects/pacmanager/ Refer: http://linuxg.net/how-to-install-pac-manager-4-5-2-on-ubuntu-linux-mint-and-debian/ PAC Manager is a GUI for SSH and telnet, similar to Putty.
Issues after upgrade from Ubuntu 14.04 to Ubuntu 16.04. Needed to run the following commands, you need to remove and re-install PAC.
$ sudo apt-get remove pac
$ sudo rm -rf /opt/pac
$ sudo dpkg -i pac-4.5.5.7-all.deb
This did NOT work:
$ find /opt/pac/ -name "Vte.so*" -exec rm {} +
Refer: https://sourceforge.net/p/pacmanager/bugs/177/
Sample Script: sample.exp (You can run this in Ubuntu)
How to run scripts:
expect -f your-file-name.exp
Refer for possible extra goodies: http://www.thegeekstuff.com/2010/12/5-expect-script-command-line-argument-examples/
Ubuntu Installation:
$ sudo apt-get install expect
$ sudo apt-get install expect-dev
Refer: http://www.admin-magazine.com/Articles/Automating-with-Expect-Scripts
Expect is a natural and intuitive automation scripting language that operates in much the same way humans do when interacting with a system. You type in commands and expect a certain response to your command. When you receive the expected response, you enter another command and so on. Expect works in the same way, except you have to provide the script with commands and expected responses to those commands. Basically, you have to script out the entire two-way “conversation.”
You can think of an Expect script as a dialog script written for two actors: a sender and a receiver. One of the more popular activities to automate is an SSH session between two hosts, in which one host is the sender (local host) and the other is the receiver (remote host). Being able to emulate every keystroke and create a true interactive session between two systems via a script is an exciting proposition.
Expect Setup
Most Linux distributions include Expect as part of the available and installable software packages. In other words, you won’t have to download and install from source code. Use your system’s package manager to download and install Expect and any required dependencies or associated packages. For example:
$ sudo yum install expect
or
$ sudo apt-get install expect
Once you have Expect installed, you can begin writing scripts.
Creating an Interactive SSH Session
As stated previously, you must provide both sides of the conversation in your script because you’re setting up an interactive system. Look at a few essential items before diving right into a script.
To make an Expect script executable as a standalone program, you must do two things: Make the script executable, and supply the path to the script for expect . The path on my system is: /usr/bin/expect ; therefore, enter that path on the first line of your script with a preceding “shebang” (#! ):
The -f switch tells Expect that it is reading commands from a file. The spawn command spawns or launches an external command for you. In this case, ssh to a remote host (aspen ):
spawn ssh aspen
Change the host aspen to your remote host. When you SSH to a remote system, you’re prompted for a password. This password prompt is what you “expect” from the remote system; therefore, you enter that expected response:
expect "password: "
From the local side, you have to enter your password at the password prompt. To send anything to the remote system, it must be included in double quotes and must include a hard return (\r ). Change PASSWORD to your password:
send "PASSWORD\r"
Again, you have to enter the expected response from the remote system, which in this case is a user prompt ($ ).
expect "$ "
Now that you’re logged in to the remote system, you can begin your interactive session on that remote host. The following send command issues the ps -ef |grep apache command:
send "ps -ef |grep apache\r"
Output will appear as STDOUT. After the command has executed, you’re returned to a prompt, so tell the Expect script that bit of information:
expect "$ "
Finally, send the exit command to the remote system to log out. Don’t forget that hard return (\r ):
send "exit\r"
The script in its entirety looks as follows:
spawn ssh aspen
expect "password: "
send "PASSWORD\r"
expect "$ "
send "ps -ef |grep apache\r"
expect "$ "
send "exit\r"
Change permissions on the script so that it is executable; for example,
$ chmod 755 script.sh
and try it for yourself.
Expect Caveats
If your script hangs and doesn’t continue, try the command manually yourself and look for the response. If the remote system drops you to a prompt as its final act, then place that in your script (e.g., expect "$ " ). Be sure you have entered the hard return (\r ) inside the closing quotation mark in your send line. You might also find that your system needs two backslashes on the send line for a hard return (\r ).
Sometimes Expect scripts execute too fast, and you won’t see your expected response. If that happens, place a sleep command and a number of seconds for the command preceeding it to wait for a response, or your data might be ignored.
For example, if you connect to a remote system and there’s a delay in creating that connection, your script will continue to execute and fail because it sends commands before the remote system has time to respond.
You have to think about network delays, shell responses and system timing when scripting in Expect. Like any scripting language, Expect has its quirks, but you’ll find that it’s an easy way to automate those repetitious keystrokes and procedures. The time you spend debugging your scripts is well worth the effort.
Autoexpect
Of course, some lazy system administrators take lazy to a higher level and even cheat at writing Expect scripts by invoking a shell “watcher” or recorder script named Autoexpect. Once invoked, Autoexpect watches your every keystroke and records it to a file named, script.exp by default. You’ll almost certainly have to edit and prune this script to achieve your desired results; however, it can save hours of script debugging to have an almost complete script from which to work.
If you simply run a freshly created Autoexpect script, it will likely fail because, if you issued a command that answers your request by displaying information to the screen, the script picks up that answer, too, and copies it into the script file.
For example, if during your Autoexpect session, you type, ls , the result of that command appears in your script.exp file as well. After you’ve created a few Expect scripts by hand, you’ll appreciate the cleanup editing you have to do in an Autoexpect-created script.
To install Autoexpect, issue a command like:
$ sudo apt-get install expect-dev
You’ll likely require many more dependencies for this feature, so prepare yourself for a slight delay while everything installs.
Creating an Interactive SSH Session with Autoexpect
After installing Autoexpect and all of its required packages, you’re ready to create Expect scripts automatically by stepping through the procedures you want to automate. Using the above example, SSH to a remote system and run a
ps -ef |grep apache
command and then log out.
Invoking Autoexpect is easy:
$ autoexpect
$ autoexpect started, file is script.exp
Although it looks as if nothing has happened or is happening, every keystroke you type will be recorded into script.exp . Every STDOUT response you receive will also be copied into that same file. Your entire session is recorded – but not just recorded, it is also formatted in Expect script style. To stop recording keystrokes to your script, press Ctrl+D on your keyboard to stop Autoexpect and copy the buffer to your file.