similar to: google cloud compute with PEM file

On 5/17/16 2:12 PM, Frank Cox wrote: > On Tue, 17 May 2016 13:59:18 -0600 > Dustin Kempter wrote: > >> Is there something I missed? > ssh -v serveryouwanttoconnectto > > That will tell you what the problem is. > > If you don't understand the output, post it here. > Here is the command and output [test1 at pgpool1 ~]$ ssh -v -i /home/test1/my-key.txt upload

On Tue, 17 May 2016 13:59:18 -0600 Dustin Kempter wrote: > Is there something I missed? ssh -v serveryouwanttoconnectto That will tell you what the problem is. If you don't understand the output, post it here. -- MELVILLE THEATRE ~ Real D 3D Digital Cinema ~ www.melvilletheatre.com

In article <573B48C8.1070000 at consistentstate.com>, Dustin Kempter <dustink at consistentstate.com> wrote: > Hi all, > I am using the google cloud compute engine and we have a client > that does not want to share their ssh keys. So I have been attempting to > set up a PEM file for ssh access. Both the local server I used for > testing and the cloud vm are

On 5/17/16 10:47 AM, Tony Mountifield wrote: > In article <573B48C8.1070000 at consistentstate.com>, > Dustin Kempter <dustink at consistentstate.com> wrote: >> Hi all, >> I am using the google cloud compute engine and we have a client >> that does not want to share their ssh keys. So I have been attempting to >> set up a PEM file for ssh access.

Hi all, I am using the google cloud compute engine and we have a client that does not want to share their ssh keys. So I have been attempting to set up a PEM file for ssh access. Both the local server I used for testing and the cloud vm are centos 6. I created a user on the cloud box, ran "ssh-keygen -t rsa" and took the defaults. I then copied the id_rsa.pub file to the local

On Tue, 17 May 2016 14:34:03 -0600 Dustin Kempter wrote: > Enter passphrase for key '/home/test1/my-key.txt': Since your private key is encrypted, have you entered the passphrase for the private key when asked at this point in the login? -- MELVILLE THEATRE ~ Real D 3D Digital Cinema ~ www.melvilletheatre.com

On Tue, 2016-05-17 at 14:34 -0600, Dustin Kempter wrote: > Connecting to 104.197.158.61 [104.197.158.61] port 22. (1) I would change the port from 22 to something more difficult to guess, perhaps 49026 (for example) and then block port 22 in the firewall. (2) Allow to port 49026 (for example) traffic from your IP and block traffic from all other IPs. Do not forget there are people out

Hey All, Can anyone tell me what the following message implies? What does PEM_read_PrivateKey do and why would it fail? This is the result of trying to setup ssh for autologin. Though I follow the man page, it doesn't work. debug1: PEM_read_PrivateKey failed Thanks, Bill Rees More Debug Output ========== debug2: service_accept: ssh-userauth debug1:

Hi On Tue, Nov 3, 2015 at 4:56 PM, Reynier Perez Mira <reynierpm at gmail.com> wrote: > I have two servers identified as `server-1 - 192.168.3.128` and `server-2 - > 192.168.3.130`. I am setting up `capifony` for automatic deployment from > server-1 to server-2 and this is what I have done so far: > > 1. In both servers I have created a user `deploy` without password since

Edit /etc/ssh/sshd_config Set: UseDNS no GSSAPIAuthentication no Save, restart sshd, try again. digimer On 16/11/16 06:07 PM, Larry Martell wrote: > I have a CentOS 7 system and when I login with putty or ssh there is a > long delay before I get the password prompt. I ran ssh -v and I found > that it gets up to this: > > debug1: ssh_ecdsa_verify: signature correct > debug1:

I have a CentOS 7 system and when I login with putty or ssh there is a long delay before I get the password prompt. I ran ssh -v and I found that it gets up to this: debug1: ssh_ecdsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received and then

I have two servers identified as `server-1 - 192.168.3.128` and `server-2 - 192.168.3.130`. I am setting up `capifony` for automatic deployment from server-1 to server-2 and this is what I have done so far: 1. In both servers I have created a user `deploy` without password since that's the user I will use for deployment. 2. In server-1 I setup a SSH keys by running the command:

On May 17, 2016, at 7:56 PM, Always Learning <centos at u68.u22.net> wrote: > (1) I would change the port from 22 to something more difficult to > guess, perhaps 49026 (for example) and then block port 22 in the > firewall. If you?re going to change the port, change it to something <1024. You don?t want to have sshd running on a port that a non-root user can bind to. --

On Tue, 2016-05-17 at 20:12 -0400, Jonathan Billings wrote: > On May 17, 2016, at 7:56 PM, Always Learning <centos at u68.u22.net> wrote: > > (1) I would change the port from 22 to something more difficult to > > guess, perhaps 49026 (for example) and then block port 22 in the > > firewall. > > If you?re going to change the port, change it to something <1024.

Hi all, I have a problem using sftp which I cannot get solved even after searching all over the web, so maybe one of you has a useful hint: I want to run a simple script that puts a file on a server using sftp. Keys are setup correctly, everything works fine if I run the script from within a terminal. When I run the same script from the crontab (my personal crontab as user) the script runs fine

https://bugzilla.mindrot.org/show_bug.cgi?id=2456 Bug ID: 2456 Summary: gssapi-keyex blocked by PermitRootLogin=without-password Product: Portable OpenSSH Version: 7.1p1 Hardware: Other OS: Linux Status: NEW Severity: minor Priority: P5 Component: sshd

Hello, I'm having a problem with my ssh client, on FreeBSD 5.4 and 6.1 the same issue. OpenSSH_3.8.1p1 FreeBSD-20040419, OpenSSL 0.9.7e 25 Oct 2004 but also same problem with OpenSSH_4.3 When I make a key, everything goes fine. When I try to change the password on the key it give me the 'PEM_read_PrivateKey failed' problem, this also prevents me from connecting to another host.

I would like to request additional consideration for inclusion of the gss-keyex patch (https://bugzilla.mindrot.org/show_bug.cgi?id=1242) into mainline OpenSSH. I know this comes up every few months, and I know that the current answer is "no" (as stated in November 2007), so I'll get straight to the new information and possibly-new arguments. 1. I conducted a careful, line-by-line

Hai, I did see that you are using Administrator, and thats the problem. Administrator is mapped to root ( most of the time ), if you assigned Administrator UID = 0 then you have a problem, because only root = uid 0. Never ever give Administrator a UID/GID, create a new one assign that one a UID/GID. So try again with a normal user, that does have a UID/GID. If that does not work, please

Thanks for the prompt reply! > I did see that you are using Administrator, and thats the problem. > Administrator is mapped to root ( most of the time ), > if you assigned Administrator UID = 0 then you have a problem, because only root = uid 0. > > Never ever give Administrator a UID/GID I am using tdb backend. It mapped administrator account to 12000:10000. > So try again