I am running fab task by using key based authentication. If any of host prompted for password, fabric should skip the host and should continue the job with next host.
I have tried with --abort-on-prompts , but this option stop the job. I want to continue the job.
Related
I reset the instance after some codes hung up the server.
and then I was not able to login with the ssh tool
In the serial port log, I found this:
.......................
[K[ [31m*[0m] A start job is running for /etc/rc....atibility (12hours 57s / no limit)
I have one serial port console now. but which commands should I use?
Please help me.
Port 22 is listening but I have not set any passwords or ssh keys. So I only can login by the google ssh web tool
This could be caused if you put long-running commands in rc.local so it is expected that the server will take some time to boot. See the Stack Exchange question in [1]
I would give the VM some time (minutes) and let it finish the processes.
If the issue persists you should contact Google Cloud Support to assist you with your VM instance. See link [2] for information on how to contact support.
[1] https://askubuntu.com/questions/616757/a-start-job-is-running-for-etc-rc-local-compatibility-how-to-fix
[2] https://support.google.com/cloud/answer/6282346?
I have a web application on one of the client's machines (a virtual machine running Windows Server 2012R2). The application uses Azure Storage. For testing purposes it was decided to use an Azure Storage Emulator.
My problem is that, when I log out of the remote machine the storage emulator stops. How do I keep the Azure Storage Emulator running even if no user is logged in?
CristisS#, There are two possible solutions i could think off based on your scenario, the first one is to configure the emulator to be part of the startup programs, meaning, if the VM restarts, the application will automatically launch,all you have to do is add the emulator icon to the startup directory:
1- Enable viewing hidden files and folders
2 Navigate to: C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup\
Paste the Emulator icon there.
Another solution is by configuring autologon and linking the application to a specific user to allow the emulator to connect automatically: https://learn.microsoft.com/en-us/sysinternals/downloads/autologon
Autologon enables you to easily configure Windows’ built-in autologon mechanism. Instead of waiting for a user to enter their name and password, Windows uses the credentials you enter with Autologon, which are encrypted in the Registry, to log on the specified user automatically.
Autologon is easy enough to use. Just run autologon.exe, fill in the dialog, and hit Enable. To turn off auto-logon, hit Disable. Also, if the shift key is held down before the system performs an autologon, the autologon will be disabled for that logon. You can also pass the username, domain and password as command-line arguments:
autologon user domain password
I'm trying to set up an AWS instance for about 90 people where they can sftp in and drop files, but it appears that AWS blocks passwords for ssh and only allows in ssh keyed logins by default.
Does there exist a way to undo this behavior inside AWS and allow for normal ssh and thus sftp to occur? If I don't need to manage ssh keys along with user names and passwords that would be great.
You can enable Password Authentication following helloV's advice, however I would advise against this.
Why would you not just use SSH keys?
Each of these 90 people should have their own private key files that they use daily - each person who needs access to this machine, you should ask for their public key.
Take each developer's public key, and add them, line by line, to a file on the EC2 host at
/home/<user>/.ssh/authorized_keys
From here, each user will be able to login using
ssh -i /path/to/private/key <user>#ec2.host.com
sftp -oIdentityFile=~/.ssh/keyfile <user>#ec2.host.com
This is much more secure in that you will not need to have a single password shared between 90+ developers, that password which will at some point be written on a sticky note and lost, or someone changes and locks out the other 89 developers.
This also has advantages in that, if a single one of those 90 developers leaves the company, all you will need to do is remove their public key from _authorized_keys_ and that person looses access to the machine, you will not need to change that shared password for all users.
First open few terminal sessions to the EC2 machine, in case modifying SSH config fails, you still have an option to restore it to its old values.
Edit /etc/ssh/sshd_config (after saving a backup file to sshd_config.bak) and change the following lines to:
# Change to no to disable tunnelled clear text passwords
PasswordAuthentication yes
In addition, if you want to disable key based authentication:
PubkeyAuthentication no
Save the file and restart the SSH daemon:
sudo service ssh restart
Create a new user and set a password or if a password has been already set for an existing user: open a new SSH session and you should be able to login using a password. If the solution didn't work, use any of the other open terminal sessions to restore the old sshd_config, restart the ssh service and continue debugging.
The critical part is to modify /etc/ssh/sshd_config on the server and restart the SSH server (usually "service sshd restart" - note it is "sshd", not "ssh" at least on Red Hat).
PasswordAuthentication yes
You may also want to run
sshd -t
before you run "service sshd restart", to make sure that you don't accidentally lock yourself out by a typo in the sshd_config file.
Using public keys for authentication probably makes more sense, depending on your scenario.
If you use public key authentication and have anything like 50 people, make sure you also manage the keys properly. See https://www.ssh.com/iam/ssh-key-management or NIST IR 7966 more information. Properly terminating keys for people who leave is also required by most compliance regulations if you happen to be in health care, finance, government, critical infrastructure, or anything else that is regulated. Shared passwords are expressly forbidden by most regulations and generally bad security practice.
You might also want to look at CryptoAuditor https://www.ssh.com/products/cryptoauditor/, which can enforce file transfer policies (direction etc), make sure you don't accidentally give people shell access if not needed, and it can record who did what (for both file transfers and shell access).
I have to login to a server from a remote server. I am able to login to remote server using phpseclib. After that I am able to login to next server from that but next command executes on firt server and not the second server. For example:
Login to server1.example.com via SSH
Login to remote-server.example.com using internal script from server1.
Execute 'ls'.
ls returns output from server1 rather remote-server.
Are you absolutely sure your script on server1 actually logs into remote-server (and does not immediately log out)? The only explanation I can think of is that the "ls" command is not really run on the remote server. If you share the script and exact commands, that could help figure it out. (Output of "script" from the whole exchange might also be helpful.)
Something like the following might also work for you:
ssh server1.example.com ssh remote-server.example.com ls
Depending on your remote command, you might also do something like:
ssh server1.example.com "ssh remote-server.example.com ls"
(The latter might be needed if there are, e.g., redirects involved that could otherwise be interpreted by your local shell.)
As you use phpseclib, that might handle the first ssh in the examples above. So you might perhaps use something like:
$ssh->exec("ssh remote-server.example.com ls")
Or if you are using public key authentication for the second step, maybe:
$ssh->exec("ssh -i ~/.ssh/keyfile remote-server.example.com ls")
There's a quick summary of how to run commands remotely with ssh at https://www.ssh.com/ssh/command/
I want to copy a file from remote1 host to the remote2 host using fabric.
I am trying to pass the password for remote2 to the fabric run command, but it's still prompting for the remote2 password.
Anything wrong with my code?
run('echo "pass123" | scp my.tar root#1.2.3.4:')
run('"pass123" | scp my.tar root#1.2.3.4:')
Edit:
In our prod and stagging environments key auth is not supported.
The OpenSSH utilities, including scp, don't accept passwords on the command line or standard input. Whey they read a password, they explicitly open the process's TTY and read from that.
There are basically four approaches available to you:
Use key-based authentication instead of passwords.
Use a program like sshpass or expect to feed the password to scp through a PTY.
Download the OpenSSH source code and modify the software to work the way you want.
Find a way to transfer these files which doesn't involve using the OpenSSH clients software.