On GCE, I added a disk to my VM and changed the fstab file to mount disk automatically. But I made a mistake in that file so I couldn't ssh this vm any more.
In my opinion, I need to edit that file correctly then I can ssh it again. The problem is I couldn't login first to edit it.
Are there some ways to fix this issue?
Using the interactive serial console to revert the changes you might have done.
Refer to this post.
create a root password for the serial console
login into the instance and revert the changes
Related
i am trying to run script that clone repository and then build it in my docker.
And it is a private repository so i have copied ssh keys in docker.
but seems like below command does not work.
yes yes | git clone (ssh link to my private repository.)
When i manually tried to run script in my local system its showing the same.but it works fine for other commands.
I have access of repository as i can type yes and it works.
But i can't type yes in docker build.
Any help will be appreciated.
This is purely an ssh issue. When ssh is connecting to a host for the "first time",1 it obtains a "host fingerprint" and prints it, then opens /dev/tty to interact with the human user so as to obtain a yes/no answer about whether it should continue connecting. You cannot defeat this by piping to its standard input.
Fortunately, ssh has about a billion options, including:
the option to obtain the host fingerprint in advance, using ssh-keyscan, and
the option to verify a host key via DNS.
The first is the one to use here: run ssh-keyscan and create a known_hosts file in the .ssh directory. Security considerations will tell you how careful to be about this (i.e., you must decide how paranoid to be).
1"First" is determined by whether there's a host key in your .ssh/known_hosts file. Since you're spinning up a Docker image that you then discard, every time is the first time. You could set up a docker image that has the file already in it, so that no time is the first time.
I want to programmatically download a file from a remote machine.
So, I know the host's IP and port:
Login data:
I also know that it creates an SSH tunnel.
Any suggestions? Is it even possible knowing just that data?
My knowledge on that topic is very scarce.
My answer focuses on SSH usage. In order to download a file via SSH, you need to run the scp command, like
scp yourusername#server.url:/the/path/to/the/file.extension ./
That's enough in order to download the file. However, it is possible that this will not work by itself. First, you need the other machine to know about your ssh, so you will need to
vim ~/.ssh/authorized_keys
hit insert and paste your public SSH key to its end. Don't remove anything. If it is still not working, then ssh might be disallowed on the server and you will need to enable it. Example for Ubuntu: https://linuxize.com/post/how-to-enable-ssh-on-ubuntu-18-04/
Your user needs access to the file you want to download, otherwise this won't work.
Alternatively you could set up an SFTP connection as well and use that.
I installed docker machine, and then created a new docker-machine on Windows 10.
Now I run ls to see the list of docker machines.
Now I run the following command
docker-machine start hypervdockermachine
Now I am stuck at this
Waiting for SSH to be available...
Too many retries waiting for SSH to be available. Last error: Maximum number of retries (60) exceeded
I have seen the git hub issue here, but not clear what to do.
Is there a way to solve this problem? I am not good at ssh
UPDATE
I just found a workaround.
You can run the above commands with git bash.
Most important, you must run git bash as admin. Else you will end up scratching your head.
Even the basic
docker-machine ls
will not show up anything without being an admin.
Finally if you are seeing the following error
Unable to query docker version: Get https://192.168.0.105:2376/v1.15/version: x509: certificate signed by unknown authority
Then you have to look at this issue.
docker-machine regenerate-certs yourdockermachinename
If needed user --force option
I got into the same problem after I moved .docker to partition D: and created a symlink to C:\Users\username\.docker, following this SO answer. I removed the old machines and configured new ones, and tried to regenerate the certs as suggested in the OP workaround but the problem was not solved.
After googling, I found this OpenSSH wiki page
and suspected that the cause of the problem was related to permissions.
So I could solve the problem by trying two different things:
Delete .ssh (source)
fix permissions to D:\path\to\.docker, allowing only SYSTEM, Administrators and my user to have full control access (source). These permissions were the same defined for .docker when it was under C:\Users\username\, but moving the folder to another partition made it inherit different permissions. To avoid dealing to much with it, I keep inheritance enabled changed the permissions directly in D: rather than in .docker folder.
I am using /etc/config/system file to change the hostname of the openwrt/lede router and after restart using "/etc/init.d/system restart" the name changed successfully. when I reboot the router, the name got changing to "lede", and also my entry in system not available. What is the actual issue here and How to solve this?.
Thanks.
Maybe your file system does not support persistent write-back to flash storage? Do all files get reset after a reboot? Does the entire /etc/config/system file get reset, or is it just just the hostname line that is reverted? Do you use any GUI or automatic tools to make configurations? A clean OpenWrt/LEDE installation does not write to any file in /etc/config/.
Also see: On reboot command router resets Openwrt Caos Calmer 15.05 for more information about problems with persistent write-back, which is most likely your issue.
Hi I can login to the GCE VM with WinSCP using my own username, cannot login as root...this is by default according to Google, and can be changed.
Changed like this:
Step 1: Login SSH and Su Root
# sudo su root
Step 2: Change password Root
#passwd root
Step 3: Config SSHD allow Root login
#nano /etc/ssh/sshd_config
PermitRootLogin yes
PasswordAuthentication yes
#service sshd restart (I used ssh as I'm using ubuntu and sshd wouldn't work)
Tried to login as root via WinSCP but I get
"Received too large (1349281121 B) SFTP packet. Max supported packet
size is 1024000 B. The error is typically caused by message printed
from startup script (like .profile). The message may start with
'Plea'." Cannot initialize SFTP protocol. Is the host running a SFTP
server?"
Any ideas?
Received too large SFTP packet. Max supported packet size is 102400 B
Cause:
This problem can arise when your .bashrc file is printing data to the screen (e.g.archey, screenfetch). The .bashrc file runs every time any console shell is initialized.
Solution:
Simply move any scripts that generate output from your .bashrc file to your .bash_profile. The .bash_profile only runs when you create a physical shell session.
NOTE: Just for anyone who comes across this and simply wants to copy files and doesn't matter what file protocol they use. You can just switch file protocol from SFTP to SCP to avoid this issue. Thought it might be worth a mention.
If you used Ubuntu linux and try to connect the server then "Please login as the Ubuntu user" you should sftp as the ubuntu user, not as root.
Try that, hope it will work for you!
Thanks!
Hmmm, I added this in WinSCP in advanced settings under "protocol options":
sudo /usr/lib/openssh/sftp-servers
I can login with my own username and move files now. Although not exactly sure how this works, I think it somehow changes you to root user at login?
More info: https://winscp.net/eng/docs/faq_su
See WinSCP article on Received too large (... B) SFTP packet. Max supported packet size is 102400 B
If … (from the subject [error message]) is a very large number then the problem is typically caused by a message printed from some profile/logon script. It violates an SFTP protocol. Some of these scripts are executed even for non-interactive (no TTY) sessions, so they cannot print anything (nor ask user to type something).
To add to #ThatOneCoder's answer on the cause being too much output from .bashrc: in e.g. Ubuntu, there is also the system wide /etc/bash.bashrc that might be "too wordy" and cause the Received too large SFTP packet error.
It's a "system wide .bashrc", and if you want to execute code for all logging in, that's one location to place it. If you nixed ~/.bashrc and still get the error, check the contents of /etc/bash.bashrc.
It is happening because you haven't given shell access permission to the user.
I faced the same issue trying to login on my ubuntu 16.04 EC2 server as "root" via WinSCP. I spent a lot of time trying to fix it but in the end a simple workaround worked for me.
I ssh into the instance using PuTTY with the username "ubuntu". After this I typed
sudo -i
and with this the user was changed to root.