how to see forge logs without entering into server with .ssh - ssh

I have laravel forge. I want to see logs. I know where it's located.
/home/forge/sitename/storage/logs.
The thing is I don't have .ssh access.
All I got is a circle account which means I am part of the team, and I can see servers and other things on laravel.forge.com.
How do I see logs without ssh into the server?

in the page My account that appears when you click on your name to the top right, you can declare an SSH key.
you can then use the key to access the forge server with the username forge.

Related

Connect to Windows server with ssh with keys

I would like to connect to a Windows server via SSH with private and public key from my local Windows machine.
The problem is that I can not figure out how and am asked to enter the password every time.
Eventually I want to setup remote coding with vs code but as the ssh program faces the same problem as in VS code I think we can leave VS code out of the picture.
Generally the connection to the server is working. So if I type ssh {myuser}#{servername} I am prompted to write my password and afterwards the console is connected to the server.
Now I would like to set it up in a way that I do not need to write my password every time, there for I setup public and private key following this tutorial.
But the system still ask my for a password each time. Does anyone know what the problem might be?
I would guess that the permissions might be an issues. In the link listed above they mentioned that I should set the permissions to 700 for the .ssh folder and 640 for the authorized_keys file. As Windows does not hove the chmod command (or at least it does not seem to change the permissions) this could be the problem.
I have also put the public key in the authorized_keys file of the .ssh folder of the user I am using.
Also as the copying with cat and | did not work I moved the files there manually but otherwise is sticked to the tutorial.
Does anyone know what the issue is?
Furthermore I managed to connect both the server and the client to a bit bucket server using ssh key with out a problem.

Google Compute Engine: Adding SSH but can't connect like in their video

OK I need help.
I have created a simple instance with Google Compute Engine, and I have added SSH keys through their META DATA section. But every time I try to log in with Putty (I can do it with their console) I get Permission denied (publickey)
Even when I log in with their browser console , I can see all the users I created with WEB UI, and public keys in authorized_keys
However I can't SSH even though my private keys are in my .ssh
I did all the checked and my ssh is enabled by default
http://screencast.com/t/zI9vDr2s
The thing was that I was accessing the site via IP, since for me the site's DNS wasn't propagated at the moment. nevertheless I tried placing domain name instead of IP and it worked. Weird because I still can't access the site via domain ... and my neighbor can.

Global ssh key on server

I work for a webdevelopment company that also manages the hosting of our customers websites.The hosting is shared and only on 3 servers. The webservers are debian webservers where each customer has his own account to reach his own website files.
Normally I would login to the server as this customer and add my ssh key to an authorized_keys file so that I can simply ssh into the account without having to lookup the password, this works perfectly fine.
The downside is I have to do this for every account over again, is there a way to add it to the server only once so that I can access all the accounts?
I tried putting the authorized_keys file in a .ssh folder in the root of the server but this doesn't seem to provide me access with any account. I have to admit my linux knowledge is limited, so am wondering if this is even possible?
You can update your sshd_config and add to AuthorizedKeysFile also for example some path in /etc/ssh/authorized_keys where you can put your master key. This would authorize you with this key to all accounts. But don't forget to leave there also the original one:
[...]
AuthorizedKeysFile .ssh/authorized_keys /etc/ssh/authorized_keys
[...]
Or you can use certificates as described in ssh-keygen manual page. This would allow you to audit the access with these keys.
You can consider to use emcSSH tool for your purposes. This is blockchain-based distributed Public Key Infrastructure and group management system.
You can read details and download here: http://emercoin.com/EMCSSH
If needed any assistance, feel free for contact me. I'm author of this system, and can answer your questions.

Google server putty connect 'Disconnected: No supported authentication methods available (server sent: publickey)

I'm trying to connect to my Debian Google Compute Engine server through PuTTy (I've tried other alternatives too) but when I do I get the error "Disconnected: No supported authentication methods available (server sent: publickey)
The google server came without a username and password, only a url to automatically login to their own terminal.
I had PuTTY working and then one day got this error.
Solution: I had revised the folder path name containing my certificates (private keys), and this caused Pageant to lose track of the certificates and so was empty.
Once I re-installed the certificate into Pageant then Putty started working again.
Turn on Password Authentication
By default, you need to use keys to ssh into your google compute engine machine, but you can turn on password authentication if you do not need that level of security.
Tip: Use the Open in browser window SSH option from your cloud console to gain access to the machine. Then switch to the root user with sudo su - root to make the configuration changes below.
Edit the /etc/ssh/sshd_config file.
Change PasswordAuthentication and ChallengeResponseAuthentication to yes.
Restart ssh /etc/init.d/ssh restart.
Please follow this guide: https://gist.github.com/feczo/7282a6e00181fde4281b
with pictures.
In short:
Using Puttygen, click 'Generate' move the mouse around as instructed and wait
Enter your desired username
Enter your password
Save the private key
Copy the entire content of the 'Public key for pasting into OpenSSH authorized_keys file' window. Make sure to copy every single character from the beginning to the very end!
Go to the Create instances page in the Google Cloud Platform Console and in the advanced options link paste the contents of your public key.
Note the IP address of the instance once it is complete.
Open putty, from the left hand menu go to Connection / SSH / Auth and define the key file location which was saved.
From the left hand menu go to Connection / Data and define the same username
Enter the IP address of your instance
name the connection below saved Sessions as 'GCE' click on 'Save'
double click the 'GCE' entry you just created
accept the identy of the host
Now login with the password you specified earlier and run
sudo su - and you are all set.
You need to use an SSH key to login to your instance.
The GCE documentation explains the process here.
I had the same problem but got it working by changing enable-oslogin from TRUE to FALSE in google cloud.
from:
to:
I had the same issue and just figured it out !!
Assuming that you already went and created private/public key added your public key on the remote server ... type in username#remotehost.com and THEN go to Connection -> SSH -> Auth and click Browse to locate your private key. After you choose it will populate the input field. After that click OPEN ...
So the important thing here is the order... make sure you first enter parameters for the host and then locate your private key.
I got this error because I had forgotten to add my username behind the key in the GCE metadata section. For instance, you are meant to add an entry into the metadata section which looks like this:
sshKeys username:key
I forgot the username: part and thus when I tried to login with that username, I got the no supported auth methods error.
Or, to turn off the ssh key requirement entirely, check out my other answer.
Apparently running sudo chmod -R a+rw on your home folder causes this to happen as well.
This problem mainly caused by your connected username not have the access to the shell in GCE. So you use the following steps to solve this issue.
gcloud auth list
If you are using the correct login. please follow the below steps. otherwise use
gcloud auth revoke --all
gcloud auth login [your-iam-user]
and you get the token or it automatically detect the token.
gcloud compute --project "{projectid}" ssh --zone "{zone_name}" "{instance_name}" .
if you dont know this above line click to compute engine-> ssh dropdown arrow-> view google command-> copy that code and use it
Now it update your metadata and it is available in your computer's folder Users->username
~/.ssh/google_compute_engine.ppk
~/.ssh/google_compute_engine.pub
Then you create a new ppk file using puttygen and you give the username, which you want like my_work_space. Then
save the publickey and privatekey in a folder.
Next step: Copy the public key data from puttygen and create new ssh key in gcloud metadata
cloud console ->compute engine->metadata->ssh key->add new item->paste the key and save it
and now return your shell commandline tool then enter
sudo chown -R my_work_space /home/my_work_space
now you connect this private key using sftp to anywhere. and it opens the files without showing the permission errors
:) happy hours.
If the private key has been generated with ssh-keygen in Linux it needs to be converted with puttygen because Putty does not support openssh keys.
Start puttygen, and click on Conversions - Import key, then click Browse and select the private key generated with openssh, then click on Save private key.
Use your new key to connect.
I faced the same issue and solve after several trial and error.
In the /etc/ssh/ssh_config, set
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PasswordAuthentication no
AuthenticationMethods publickey
then, open putty.
In the "Saved Sessions", enter the server IP, go through the path Connection->SSH->Auth->Browse on the left panel to search your private key and open it.
Last but not least, go back to Session of putty on the left panel and you can see the server IP address is still in the field, "Saved Sessions", then click "Save", which is the critical step.
It will let the user login without password any more.
Have fun,
Download "PuttyGEN" get publickey and privatekey
use gcloud SSH edit and paste your publickey located in /home/USER/.ssh/authorized_keys
sudo vim ~/.ssh/authorized_keys
Tap the i key to paste publicKEY.
To save, tap Esc, :, w, q, Enter.
Edit the /etc/ssh/sshd_config file.
sudo vim /etc/ssh/sshd_config
Change
PasswordAuthentication no
[...]
ChallengeResponseAuthentication to no.
[...]
UsePAM no
[...]
Restart ssh
/etc/init.d/ssh restart.
the rest config your putty as tutorial
NB:choose the pageant add keys and start session would be better
Electricity went down and got this error. Solution was to double click your .ppk (Putty Private Key) and enter your password.
PasswordAuthentication and ChallengeResponseAuthentication default set to NO in rhel7.
Change them to NO and restart sshd.
Similar problem - same error message. I got the same message when trying to clone something from bitbucket with ssh. The problem was in my ssh configuration configured in the mercurial.ini: I used the wrong bitbucket username. After I corrected the user name things worked.
For me these was my problem, solution from https://unix.stackexchange.com/questions/282908/server-refused-public-key-signature-despite-accepting-key-putty
"Looking at the log /var/log/secure showed that it was just downright refused. I'm somewhat new to centos since I'm mainly a debian kind of guy, so I was unaware of /var/log/secure
After checking this and doing a bit of searching, it turns out PermitRootLogin no needs to be PermitRootLogin without-password if you want to specifically use just keys for root login. That did the trick. Thanks everyone for contributing."
I had the same error message and discovered that my mistake was in the username I used with putty. Apparently GCE SSH Keys listing would change your username characters in some of the listing. In my case, the underscore was changed to period. i.e: my_username becomes my.username
I inadvertently copied the wrong username from the listing and got the same error message.
I know this is an old question, but I had the same problem and solved it thanks to this answer.
I use Putty regularly and have never had any problems. I use and have always used public key authentication. Today I could not connect again to my server, without changing any settings.
Then I saw the answer and remembered that I inadvertently ran chmod 777 . in my user's home directory. I connected from somewhere else and simply ran chmod 755 ~. Everything was back to normal instantly, I didn't even have to restart sshd.
I hope I saved some time from someone

SSH key access won't work after tinkering with Samba on server

I spent some time logged into a server (Debian) trying to get Samba access to work better from my Mac.
After logging out and attempting to log back in I was unable to log in using my private key which has been working for years.
Private key login worked for another user from the same client machine, and I was able to modify the sshd.config to allow password login so that I could log back onto the server.
What could I have done to break the keyed login just for my username and why?
I was messing around with creating a Samba password for my username, and I also made my home folder 777 to try to get write access working from Samba. (This was NOT a recursive chmod so the folders below are not 777.)
Your home directory should never be ugo+rwx (777). You should not allow other users to write to your home directory. The ssh daemon checks for file system permissions and will refuse to use the contents of ~/.ssh/ if it or its parent (~/) is writable by other users.
See http://www.openssh.org/faq.html question # 3.14.
Also see 'man sshd_config' and StrictModes (don't turn it off).
Hope this helps.
You can turn on logging in your sshd config if it isn't already. That'll tell you exactly what went wrong. It's often a permission problem on the files in ~/.ssh
The logfile is usually in either /var/log/secure or /var/log/auth.log
There is another possibility that none of the earlier answers have raised: SELinux. If this is active, it will prevent the .ssh folder from being accessed via a Samba share.
It is easy to test: temporarily disable SELinux ("setenforce 0") and see if the .ssh folder can be accessed.