Search Results

Search found 4906 results on 197 pages for 'ssh tunnel'.

Page 8/197 | < Previous Page | 4 5 6 7 8 9 10 11 12 13 14 15  | Next Page >

• Unable to connect to Cygwin from Mac OS X by ssh

  - by skyjack

  I've started ssh server on Windows 7 using Cywgin and I'm trying to connect to it by ssh from Mac OS X Mavericks. It fails with next error: ./ssh username@hostname -v OpenSSH_6.6, OpenSSL 1.0.1g 7 Apr 2014 debug1: Reading configuration data /usr/local/etc/ssh/ssh_config debug1: Connecting to hostname [my ip] port 22. debug1: Connection established. debug1: identity file /Users/skyjack/.ssh/id_rsa type -1 debug1: identity file /Users/skyjack/.ssh/id_rsa-cert type -1 debug1: identity file /Users/skyjack/.ssh/id_dsa type -1 debug1: identity file /Users/skyjack/.ssh/id_dsa-cert type -1 debug1: identity file /Users/skyjack/.ssh/id_ecdsa type -1 debug1: identity file /Users/skyjack/.ssh/id_ecdsa-cert type -1 debug1: identity file /Users/skyjack/.ssh/id_ed25519 type -1 debug1: identity file /Users/skyjack/.ssh/id_ed25519-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.6 ssh_exchange_identification: read: Connection reset by peer Meanwhile I can connect successfully from Red Hat. OpenSSH version on Cygwin: OpenSSH_6.4p1, OpenSSL 1.0.1f 6 Jan 2014 OpenSSH version on MAC OS X: OpenSSH_6.6p1, OpenSSL 1.0.1g 7 Apr 2014 Please advice.

  Read the article

• How to use ssh-agent (and graphic passphrase dialog) in Kubuntu 10.10?

  - by halo

  I have recently switched from Ubuntu to kubuntu, both version 10.10. Unfortunately in KDE the ssh passphrase dialog doesn't work out of the box. Everytime my ssh private key is used I need to enter my password. This is neither secure nor comfortable. I have done comprehensive research on the net but only found out dated documentation. Several things I tried didn't work out. Current status: SSH setup working with direct passphrase input ssh-agent running in X session $SSH_AUTH_SOCK set to ssh-agent's socket in X session How to enable ssh-agent for keeping the passphrase in memory for ~15mins and as a bonus always use a graphical dialog for its input? I use asymmetric SSH key pairs for pushing/pulling in Git VCS logging remotely into different server systems

  Read the article

• How to use ssh-agent (and graphic passphrase dialog) in Kubuntu 10.10?

  - by halo

  I have recently switched from Ubuntu to kubuntu, both version 10.10. Unfortunately in KDE the ssh passphrase dialog doesn't work out of the box. Everytime my ssh private key is used I need to enter my password. This is neither secure nor comfortable. I have done comprehensive research on the net but only found out dated documentation. Several things I tried didn't work out. Current status: SSH setup working with direct passphrase input ssh-agent running in X session $SSH_AUTH_SOCK set to ssh-agent's socket in X session How to enable ssh-agent for keeping the passphrase in memory for ~15mins and as a bonus always use a graphical dialog for its input? I use asymmetric SSH key pairs for pushing/pulling in Git VCS logging remotely into different server systems

  Read the article

• Trouble Setting up Open SSH with Putty

  - by warpstack

  I for the life of me can't seem to get openSSH to work on Ubuntu Server 10.10 with keys I generated in PuttyGen on my Windows machine. After hours of trial and error and web searches I can't get my ssh service to accept my private key! Here is my sshd_config. I generated my public and private keys using Putty in Windows then used a ssh connection to paste my key from putty directly into my authorized_keys2 file located in */etc/ssh/publickeys/authorized_keys2* The authorized_keys2 file looks something like: ssh-rsa AAAAB3NzaC1yc2EAAAA... with no email or anything at the end of it. I just pasted it straight from PuttyGen without using a key comment. I feel like it's not working because of some nuance I am not understanding or some unusual setting or incompatibility. I've restarted the ssh service (and the machine) to no avail. What are some common pitfalls I might have gotten myself into? Is there a simpler way to generate ssh keys that putty can use in windows?

  Read the article

• What's the risk of upgrading over SSH?

  - by C. Ross

  When I run sudo do-release-upgrade over ssh, I get the following message. This session appears to be running under ssh. It is not recommended to perform a upgrade over ssh currently because in case of failure it is harder to recover. If you continue, an additional ssh daemon will be started at port '9004'. Do you want to continue? What is the real risk of upgrading over ssh? How does the additional ssh daemon help mitigate this?

  Read the article

• ssh many users to one home

  - by filippo

  Hiya, I want to allow some trusted users to scp files into my server (to an specific user), but I do not want to give these users a home, neither ssh login. I'm having problems to understand the correct settings of users/groups I have to create to allow this to happen. I will put an example; Having: MyUser@MyServer MyUser belongs to the group MyGroup MyUser's home will be lets say, /home/MyUser SFTPGuy1@OtherBox1 SFTPGuy2@OtherBox2 They give me their id_dsa.pub's and I add it to my authorized_keys I reckon then, I'd do in my server something like useradd -d /home/MyUser -s /bin/false SFTPGuy1 (and the same for the other..) And for the last, useradd -G MyGroup SFTPGuy1 (then again, for the other guy) I'd expect then, the SFTPGuys to be able to sftp -o IdentityFile=id_dsa MyServer and to be taken to MyUser's home... Well, this is not the case... SFTP just keeps asking me for a password. Could someone point out what am I missing? Thanks a mil, f. [EDIT: Messa in StackOverflow asked me if authorized_keys file was readable to the other users (members of MyGroup). Its an interesting point, this was my answer: Well, it wasn't (it was 700), but then I changed the permissions of the .ssh dir and the auth file to 750 though still no effect. Guess it's worth mentioning that my home dir ( /home/MyUser) is also readable for the group; most dirs being 750 and the specific folder where they'd drop files is 770. Nevertheless, about the auth file, I reckon the authentication would be performed by the local user on MyServer, isn't it? if so, I don't understand the need for other users to read it... well.. just wondering. ]

  Read the article

• ssh refuses to authenticate keys

  - by MixturaDementiae

  So I am setting up a connection between my machine [fedora 17] and a virtual machine running in Virtual Box in which is running CentOS 5. I have installed openssh from the repositories on CentOS, and I have configured everything as it follows: Protocol 2 HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_dsa_key SyslogFacility AUTHPRIV PermitRootLogin yes RSAAuthentication yes PubkeyAuthentication yes AuthorizedKeysFile /home/pigreco/.ssh/authorized_keys PasswordAuthentication no ChallengeResponseAuthentication yes GSSAPIAuthentication yes GSSAPICleanupCredentials yes UsePAM yes AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE AcceptEnv XMODIFIERS X11Forwarding yes Subsystem sftp /usr/libexec/openssh/sftp-server this is the configuration file sshd_config on the server i.e. on the CentOS. Moreover I have created a public/private key pair as usual on the .ssh/ folder in my home directory in my OS, i.e. Fedora, and then I've copied with scp the id_rsa.pub to the server and then I have appended its content to the file .ssh/authorized_keys on the server machine. The error that I get is the following: OpenSSH_5.9p1, OpenSSL 1.0.0j-fips 10 May 2012 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 50: Applying options for * debug1: Connecting to 192.168.100.13 [192.168.100.13] port 22. debug1: Connection established. debug1: identity file /home/mayhem/.ssh/identity type -1 debug1: identity file /home/mayhem/.ssh/identity-cert type -1 debug1: identity file /home/mayhem/.ssh/id_rsa type 1 debug1: identity file /home/mayhem/.ssh/id_rsa-cert type -1 debug1: identity file /home/mayhem/.ssh/id_dsa type -1 debug1: identity file /home/mayhem/.ssh/id_dsa-cert type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3 debug1: match: OpenSSH_5.3 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.9 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-ctr hmac-md5 none debug1: kex: client->server aes128-ctr hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Server host key: RSA 16:e5:72:d1:37:94:1b:5e:3d:3a:e5:da:6f:df:0c:08 debug1: Host '192.168.100.13' is known and matches the RSA host key. debug1: Found key in /home/mayhem/.ssh/known_hosts:1 debug1: ssh_rsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: Roaming not allowed by server debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,keyboard-interactive debug1: Next authentication method: gssapi-keyex debug1: No valid Key exchange context debug1: Next authentication method: gssapi-with-mic debug1: Unspecified GSS failure. Minor code may provide more information Cannot determine realm for numeric host address debug1: Unspecified GSS failure. Minor code may provide more information Cannot determine realm for numeric host address debug1: Unspecified GSS failure. Minor code may provide more information debug1: Unspecified GSS failure. Minor code may provide more information Cannot determine realm for numeric host address debug1: Next authentication method: publickey debug1: Offering RSA public key: /home/mayhem/.ssh/id_rsa debug1: Server accepts key: pkalg ssh-rsa blen 279 Agent admitted failure to sign using the key. debug1: Trying private key: /home/mayhem/.ssh/identity debug1: Trying private key: /home/mayhem/.ssh/id_dsa debug1: Next authentication method: keyboard-interactive Do you have some good suggestion of what I can do? thank you

  Read the article

• Sharing public key with ssh

  - by jtnire

  Hi Everyone, Is it possible to somehow setup an ssh server that doesn't require a username,password or cert to login? If that's not possible, if I were to give all customers the same public key, would each connection be encrypted individually? (i.e. user A coudn't decrypt the payload of user B's connection) I wish to provide access to a single program, which will prompt for a username and password. Encryption is essential though, and users must not be able to snoop in on each other Thanks

  Read the article

• Oracle Linux Tips and Tricks: Using SSH

  - by Robert Chase

  Out of all of the utilities available to systems administrators ssh is probably the most useful of them all. Not only does it allow you to log into systems securely, but it can also be used to copy files, tunnel IP traffic and run remote commands on distant servers. It’s truly the Swiss army knife of systems administration. Secure Shell, also known as ssh, was developed in 1995 by Tau Ylonen after the University of Technology in Finland suffered a password sniffing attack. Back then it was common to use tools like rcp, rsh, ftp and telnet to connect to systems and move files across the network. The main problem with these tools is they provide no security and transmitted data in plain text including sensitive login credentials. SSH provides this security by encrypting all traffic transmitted over the wire to protect from password sniffing attacks. One of the more common use cases involving SSH is found when using scp. Secure Copy (scp) transmits data between hosts using SSH and allows you to easily copy all types of files. The syntax for the scp command is: scp /pathlocal/filenamelocal remoteuser@remotehost:/pathremote/filenameremote In the following simple example, I move a file named myfile from the system test1 to the system test2. I am prompted to provide valid user credentials for the remote host before the transfer will proceed.  If I were only using ftp, this information would be unencrypted as it went across the wire.  However, because scp uses SSH, my user credentials and the file and its contents are confidential and remain secure throughout the transfer.  [user1@test1 ~]# scp /home/user1/myfile user1@test2:/home/user1user1@test2's password: myfile                                    100%    0     0.0KB/s   00:00 You can also use ssh to send network traffic and utilize the encryption built into ssh to protect traffic over the wire. This is known as an ssh tunnel. In order to utilize this feature, the server that you intend to connect to (the remote system) must have TCP forwarding enabled within the sshd configuraton. To enable TCP forwarding on the remote system, make sure AllowTCPForwarding is set to yes and enabled in the /etc/ssh/sshd_conf file: AllowTcpForwarding yes Once you have this configured, you can connect to the server and setup a local port which you can direct traffic to that will go over the secure tunnel. The following command will setup a tunnel on port 8989 on your local system. You can then redirect a web browser to use this local port, allowing the traffic to go through the encrypted tunnel to the remote system. It is important to select a local port that is not being used by a service and is not restricted by firewall rules.  In the following example the -D specifies a local dynamic application level port forwarding and the -N specifies not to execute a remote command.   ssh –D 8989 [email protected] -N You can also forward specific ports on both the local and remote host. The following example will setup a port forward on port 8080 and forward it to port 80 on the remote machine. ssh -L 8080:farwebserver.com:80 [email protected] You can even run remote commands via ssh which is quite useful for scripting or remote system administration tasks. The following example shows how to  log in remotely and execute the command ls –la in the home directory of the machine. Because ssh encrypts the traffic, the login credentials and output of the command are completely protected while they travel over the wire. [rchase@test1 ~]$ ssh rchase@test2 'ls -la'rchase@test2's password: total 24drwx------  2 rchase rchase 4096 Sep  6 15:17 .drwxr-xr-x. 3 root   root   4096 Sep  6 15:16 ..-rw-------  1 rchase rchase   12 Sep  6 15:17 .bash_history-rw-r--r--  1 rchase rchase   18 Dec 20  2012 .bash_logout-rw-r--r--  1 rchase rchase  176 Dec 20  2012 .bash_profile-rw-r--r--  1 rchase rchase  124 Dec 20  2012 .bashrc You can execute any command contained in the quotations marks as long as you have permission with the user account that you are using to log in. This can be very powerful and useful for collecting information for reports, remote controlling systems and performing systems administration tasks using shell scripts. To make your shell scripts even more useful and to automate logins you can use ssh keys for running commands remotely and securely without the need to enter a password. You can accomplish this with key based authentication. The first step in setting up key based authentication is to generate a public key for the system that you wish to log in from. In the following example you are generating a ssh key on a test system. In case you are wondering, this key was generated on a test VM that was destroyed after this article. [rchase@test1 .ssh]$ ssh-keygen -t rsaGenerating public/private rsa key pair.Enter file in which to save the key (/home/rchase/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/rchase/.ssh/id_rsa.Your public key has been saved in /home/rchase/.ssh/id_rsa.pub.The key fingerprint is:7a:8e:86:ef:59:70:ef:43:b7:ee:33:03:6e:6f:69:e8 rchase@test1The key's randomart image is:+--[ RSA 2048]----+|                 ||  . .            ||   o .           ||    . o o        ||   o o oS+       ||  +   o.= =      ||   o ..o.+ =     ||    . .+. =      ||     ...Eo       |+-----------------+ Now that you have the key generated on the local system you should to copy it to the target server into a temporary location. The user’s home directory is fine for this. [rchase@test1 .ssh]$ scp id_rsa.pub rchase@test2:/home/rchaserchase@test2's password: id_rsa.pub                  Now that the file has been copied to the server, you need to append it to the authorized_keys file. This should be appended to the end of the file in the event that there are other authorized keys on the system. [rchase@test2 ~]$ cat id_rsa.pub >> .ssh/authorized_keys Once the process is complete you are ready to login. Since you are using key based authentication you are not prompted for a password when logging into the system.   [rchase@test1 ~]$ ssh test2Last login: Fri Sep  6 17:42:02 2013 from test1 This makes it much easier to run remote commands. Here’s an example of the remote command from earlier. With no password it’s almost as if the command ran locally. [rchase@test1 ~]$ ssh test2 'ls -la'total 32drwx------  3 rchase rchase 4096 Sep  6 17:40 .drwxr-xr-x. 3 root   root   4096 Sep  6 15:16 ..-rw-------  1 rchase rchase   12 Sep  6 15:17 .bash_history-rw-r--r--  1 rchase rchase   18 Dec 20  2012 .bash_logout-rw-r--r--  1 rchase rchase  176 Dec 20  2012 .bash_profile-rw-r--r--  1 rchase rchase  124 Dec 20  2012 .bashrc As a security consideration it's important to note the permissions of .ssh and the authorized_keys file.  .ssh should be 700 and authorized_keys should be set to 600.  This prevents unauthorized access to ssh keys from other users on the system.   An even easier way to move keys back and forth is to use ssh-copy-id. Instead of copying the file and appending it manually to the authorized_keys file, ssh-copy-id does both steps at once for you.  Here’s an example of moving the same key using ssh-copy-id.The –i in the example is so that we can specify the path to the id file, which in this case is /home/rchase/.ssh/id_rsa.pub [rchase@test1]$ ssh-copy-id -i /home/rchase/.ssh/id_rsa.pub rchase@test2 One of the last tips that I will cover is the ssh config file. By using the ssh config file you can setup host aliases to make logins to hosts with odd ports or long hostnames much easier and simpler to remember. Here’s an example entry in our .ssh/config file. Host dev1 Hostname somereallylonghostname.somereallylongdomain.com Port 28372 User somereallylongusername12345678 Let’s compare the login process between the two. Which would you want to type and remember? ssh somereallylongusername12345678@ somereallylonghostname.somereallylongdomain.com –p 28372 ssh dev1 I hope you find these tips useful.  There are a number of tools used by system administrators to streamline processes and simplify workflows and whether you are new to Linux or a longtime user, I'm sure you will agree that SSH offers useful features that can be used every day.  Send me your comments and let us know the ways you  use SSH with Linux.  If you have other tools you would like to see covered in a similar post, send in your suggestions.

  Read the article

• SSH is not working .. Password promt is not coming

  - by Sumanth Lingappa

  I am not able to SSH into my ubuntu server since yesterday. I am not using any keyless or public key method.. Its simple SSH with username and password everytime.. However I can do a VNC session running on my ubuntu server.. But I am afraid that if the vnc session goes out, I wont be having any way to login to the server.. My ssh-vvv output is as below.. sumanth@sumanth:~$ ssh -vvv user@serverIP OpenSSH_6.6.1, OpenSSL 1.0.1f 6 Jan 2014 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: Applying options for * debug2: ssh_connect: needpriv 0 debug1: Connecting to 172.16.2.156 [172.16.2.156] port 22. debug1: Connection established. debug1: identity file /home/sumanth/.ssh/id_rsa type -1 debug1: identity file /home/sumanth/.ssh/id_rsa-cert type -1 debug1: identity file /home/sumanth/.ssh/id_dsa type -1 debug1: identity file /home/sumanth/.ssh/id_dsa-cert type -1 debug1: identity file /home/sumanth/.ssh/id_ecdsa type -1 debug1: identity file /home/sumanth/.ssh/id_ecdsa-cert type -1 debug1: identity file /home/sumanth/.ssh/id_ed25519 type -1 debug1: identity file /home/sumanth/.ssh/id_ed25519-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2 debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1 Debian-5ubuntu1 debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1 pat OpenSSH_5* compat 0x0c000000 debug2: fd 3 setting O_NONBLOCK debug3: load_hostkeys: loading entries for host "172.16.2.156" from file "/home/sumanth/.ssh/known_hosts" debug3: load_hostkeys: found key type ECDSA in file /home/sumanth/.ssh/known_hosts:5 debug3: load_hostkeys: loaded 1 keys debug3: order_hostkeyalgs: prefer hostkeyalgs: [email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: [email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,[email protected],[email protected],[email protected],[email protected],[email protected],ssh-ed25519,ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,[email protected],[email protected],[email protected],aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected] debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,[email protected],[email protected],[email protected],aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected] debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-md5,hmac-sha1,[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-md5,hmac-sha1,[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,[email protected],zlib debug2: kex_parse_kexinit: none,[email protected],zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256 debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected] debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected] debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,[email protected] debug2: kex_parse_kexinit: none,[email protected] debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_setup: setup hmac-md5 debug1: kex: server->client aes128-ctr hmac-md5 none debug2: mac_setup: setup hmac-md5 debug1: kex: client->server aes128-ctr hmac-md5 none debug1: sending SSH2_MSG_KEX_ECDH_INIT debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: Server host key: ECDSA ea:4e:15:52:15:dd:6b:09:d4:36:cb:14:2d:c3:1b:7a debug3: load_hostkeys: loading entries for host "172.16.2.156" from file "/home/sumanth/.ssh/known_hosts" debug3: load_hostkeys: found key type ECDSA in file /home/sumanth/.ssh/known_hosts:5 debug3: load_hostkeys: loaded 1 keys debug1: Host '172.16.2.156' is known and matches the ECDSA host key. debug1: Found key in /home/sumanth/.ssh/known_hosts:5 debug1: ssh_ecdsa_verify: signature correct debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: Roaming not allowed by server debug1: SSH2_MSG_SERVICE_REQUEST sent debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug2: key: /home/sumanth/.ssh/id_rsa ((nil)), debug2: key: /home/sumanth/.ssh/id_dsa ((nil)), debug2: key: /home/sumanth/.ssh/id_ecdsa ((nil)), debug2: key: /home/sumanth/.ssh/id_ed25519 ((nil)),

  Read the article

• SSH Public Key - No supported authentication methods available (server sent public key)

  - by F21

  I have a 12.10 server setup in a virtual machine with its network set to bridged (essentially will be seen as a computer connected to my switch). I installed opensshd via apt-get and was able to connect to the server using putty with my username and password. I then set about trying to get it to use public/private key authentication. I did the following: Generated the keys using PuttyGen. Moved the public key to /etc/ssh/myusername/authorized_keys (I am using encrypted home directories). Set up sshd_config like so: PubkeyAuthentication yes AuthorizedKeysFile /etc/ssh/%u/authorized_keys StrictModes no PasswordAuthentication no UsePAM yes When I connect using putty or WinSCP, I get an error saying No supported authentication methods available (server sent public key). If I run sshd in debug mode, I see: PAM: initializing for "username" PAM: setting PAM_RHOST to "192.168.1.7" PAM: setting PAM_TTY to "ssh" userauth-request for user username service ssh-connection method publickey [preauth] attempt 1 failures 0 [preauth] test whether pkalg/pkblob are acceptable [preauth[ Checking blacklist file /usr/share/ssh/blacklist.RSA-1023 Checking blacklist file /etc/ssh/blacklist.RSA-1023 temporarily_use_uid: 1000/1000 (e=0/0) trying public key file /etc/ssh/username/authorized_keys fd4 clearing O_NONBLOCK restore_uid: 0/0 Failed publickey for username from 192.168.1.7 port 14343 ssh2 Received disconnect from 192.168.1.7: 14: No supported authentication methods available [preauth] do_cleanup [preauth] monitor_read_log: child log fd closed do_cleanup PAM: cleanup Why is this happening and how can I fix this?

  Read the article

• Tunneling traffic through a proxy using SSH - what does the proxy server see?

  - by nilu

  If I am accessing information (in a browser or via bittorent) through an SSH tunnel, what info will then be possible to obtain on the SSH/proxy server itself? As far as I have understood, the information between the proxy server and my computer is encrypted, but is it not possible for the SSH server admin to obtain info about the traffic? The SSH session requires my credentials, so my guess would be that the server admin would be able to obtain any information about my network usage.

  Read the article

• Does ssh-copy-id overwrite previous keys?

  - by decker

  I haven't yet found any definitive answer on this using google. It seems like the answer is no, but I need to know for sure before I go ahead and do it. Does ssh-copy-id append the key to authorized_keys or does it overwrite the previous keys? Thanks. Addendum: So the answer is right there in the man page. Go figure. I guess the question can at least help fellow Google-jockeys like me who get a little too used to googling and finding tutorials (that often explain things in layman's terms for us poor folks who have only used Windows our whole lives).

  Read the article

• Invalid SSH key error in juju when using it with MAAS

  - by Captain T

  This is the output of juju from a clean install with 2 nodes all running 12.04 juju bootstrap - finishes with no errors and allocates the machine to the user but still no joy after juju environment-destroy and rebuild with different users and different nodes. root@cloudcontrol:/storage# juju -v status 2012-06-07 11:19:47,602 DEBUG Initializing juju status runtime 2012-06-07 11:19:47,621 INFO Connecting to environment... 2012-06-07 11:19:47,905 DEBUG Connecting to environment using node-386077143930... 2012-06-07 11:19:47,906 DEBUG Spawning SSH process with remote_user="ubuntu" remote_host="node-386077143930" remote_port="2181" local_port="57004". The authenticity of host 'node-386077143930 (10.5.5.113)' can't be established. ECDSA key fingerprint is 31:94:89:62:69:83:24:23:5f:02:70:53:93:54:b1:c5. Are you sure you want to continue connecting (yes/no)? yes 2012-06-07 11:19:52,102 ERROR Invalid SSH key 2012-06-07 11:19:52,426:18541(0x7feb13b58700):ZOO_INFO@log_env@658: Client environment:zookeeper.version=zookeeper C client 3.3.5 2012-06-07 11:19:52,426:18541(0x7feb13b58700):ZOO_INFO@log_env@662: Client environment:host.name=cloudcontrol 2012-06-07 11:19:52,426:18541(0x7feb13b58700):ZOO_INFO@log_env@669: Client environment:os.name=Linux 2012-06-07 11:19:52,426:18541(0x7feb13b58700):ZOO_INFO@log_env@670: Client environment:os.arch=3.2.0-23-generic 2012-06-07 11:19:52,426:18541(0x7feb13b58700):ZOO_INFO@log_env@671: Client environment:os.version=#36-Ubuntu SMP Tue Apr 10 20:39:51 UTC 2012 2012-06-07 11:19:52,428:18541(0x7feb13b58700):ZOO_INFO@log_env@679: Client environment:user.name=sysadmin 2012-06-07 11:19:52,428:18541(0x7feb13b58700):ZOO_INFO@log_env@687: Client environment:user.home=/root 2012-06-07 11:19:52,428:18541(0x7feb13b58700):ZOO_INFO@log_env@699: Client environment:user.dir=/storage 2012-06-07 11:19:52,428:18541(0x7feb13b58700):ZOO_INFO@zookeeper_init@727: Initiating client connection, host=localhost:57004 sessionTimeout=10000 watcher=0x7feb11afc6b0 sessionId=0 sessionPasswd=<null> context=0x2dc7d20 flags=0 2012-06-07 11:19:52,429:18541(0x7feb0e856700):ZOO_ERROR@handle_socket_error_msg@1579: Socket [127.0.0.1:57004] zk retcode=-4, errno=111(Connection refused): server refused to accept the client 2012-06-07 11:19:55,765:18541(0x7feb0e856700):ZOO_ERROR@handle_socket_error_msg@1579: Socket [127.0.0.1:57004] zk retcode=-4, errno=111(Connection refused): server refused to accept the client I have tried numerous ways of creating the keys with ssh-keygen -t rsa -b 2048, ssh-keygen -t rsa, ssh-keygen, and i have tried adding those to MAAS web config page, but always get the same result. I have added the appropriate public key afterwards to the ~/.ssh/authorized_keys I can also ssh to the node, but as I have not been asked to give it a user name or password or set up any sort of account, I cannot manually ssh into the node. The setup of the node is all handled by maas server. It seems like a simple error of looking at the wrong key or looking in the wrong places, only other suggestions I can find are to destroy the environment and rebuild (but that didn't work umpteen times now) or leave it to build the instance once the node has powered up, but I have left for a few hours, and left overnight to build with no luck.

  Read the article

• How do you preseed an ssh key?

  - by Wes Felter

  I tried this: d-i preseed/late_command string mkdir -p /target/root/.ssh d-i preseed/late_command string cp /cdrom/id_rsa.pub /target/root/.ssh/authorized_keys d-i preseed/late_command string chmod -R go-rwx /target/root/.ssh (I'm using a USB installer and I put id_rsa.pub in the root directory of the USB drive.) The /root/.ssh directory is not created and the installer complains that the chmod command failed (not surprising if the directory doesn't exist).

  Read the article

• Gnome-terminal doesn't close at end of SSH session

  - by Simón

  I have defined in gnome-terminal that it closes at end of shell. When I press Control-D or I execute exit, the terminal closes. But if I open the SSH session with gnome-terminal -x ssh server and I execute reboot in the SSH session (to reboot the remote server), it hangs and it doesn't close. What's happening? This worked to me before but I have to reinstall my Ubuntu (in local) and now gnome-terminal doesn't close itself when SSH session ends.

  Read the article

• ssh: connect to host xxx.xxx.xxx.xxx port 22: Connection refused

  - by Umair Mustafa

  Well im trying to connect to a client machine using ssh using this command ssh root@ip-of-server It immediately slaps me with this error ssh: connect to host xxx.xxx.xxx.xxx port 22: Connection refused Then I tried to access a local server using same command it worked. For further experiment I tried to do ssh [email protected] It displayed the same error Whats wrong here. Any suggestion

  Read the article

• ssh connection error

  - by evaG

  I'm trying to log into a ubuntu desktop. I get the following error message: PTY allocation request failed What does it mean and how to connect to my desktop ? Thanks edit: debug1: Reading configuration data /home/evag/.ssh/config debug1: /home/evag/.ssh/config line 1: Applying options for * debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: Applying options for * debug1: auto-mux: Trying existing master debug1: mux_client_request_session: master session id: 2 PTY allocation request failed

  Read the article

• ubuntu ssh does not connect

  - by bocca

  SSH won't be able to establish a connection to our server Here's the output of ssh -vvv: ssh -v -v -v 11.11.11.11 OpenSSH_5.1p1 Debian-6ubuntu2, OpenSSL 0.9.8g 19 Oct 2007 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug2: ssh_connect: needpriv 0 debug1: Connecting to 11.11.11.11 [11.11.11.11] port 22. debug1: Connection established. debug1: permanently_set_uid: 0/0 debug1: identity file /root/.ssh/identity type -1 debug1: identity file /root/.ssh/id_rsa type -1 debug1: identity file /root/.ssh/id_dsa type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1p1 Debian-5ubuntu1 debug1: match: OpenSSH_5.1p1 Debian-5ubuntu1 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.1p1 Debian-6ubuntu2 debug2: fd 3 setting O_NONBLOCK debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,[email protected],aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,[email protected],aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,[email protected],zlib debug2: kex_parse_kexinit: none,[email protected],zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,[email protected],aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,[email protected],aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,[email protected] debug2: kex_parse_kexinit: none,[email protected] debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_setup: found hmac-md5 debug1: kex: server->client aes128-cbc hmac-md5 none debug2: mac_setup: found hmac-md5 debug1: kex: client->server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug2: dh_gen_key: priv key bits set: 133/256 debug2: bits set: 486/1024 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug3: check_host_in_hostfile: filename /root/.ssh/known_hosts debug3: check_host_in_hostfile: match line 1 debug1: Host '11.11.11.11' is known and matches the RSA host key. debug1: Found key in /root/.ssh/known_hosts:1 debug2: bits set: 497/1024 debug1: ssh_rsa_verify: signature correct debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug2: key: /root/.ssh/identity ((nil)) debug2: key: /root/.ssh/id_rsa ((nil)) debug2: key: /root/.ssh/id_dsa ((nil)) debug1: Authentications that can continue: publickey,password debug3: start over, passed a different list publickey,password debug3: preferred gssapi-keyex,gssapi-with-mic,gssapi,publickey,keyboard-interactive,password debug3: authmethod_lookup publickey debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Trying private key: /root/.ssh/identity debug3: no such identity: /root/.ssh/identity debug1: Trying private key: /root/.ssh/id_rsa debug3: no such identity: /root/.ssh/id_rsa debug1: Trying private key: /root/.ssh/id_dsa debug3: no such identity: /root/.ssh/id_dsa debug2: we did not send a packet, disable method debug3: authmethod_lookup password debug3: remaining preferred: ,password debug3: authmethod_is_enabled password debug1: Next authentication method: password [email protected]'s password: debug3: packet_send2: adding 64 (len 57 padlen 7 extra_pad 64) debug2: we sent a password packet, wait for reply debug1: Authentication succeeded (password). debug1: channel 0: new [client-session] debug3: ssh_session2_open: channel_new: 0 debug2: channel 0: send open debug1: Requesting [email protected] debug1: Entering interactive session. debug2: callback start debug2: client_session2_setup: id 0 debug2: channel 0: request pty-req confirm 1 debug3: tty_make_modes: ospeed 38400 debug3: tty_make_modes: ispeed 38400 debug1: Sending environment. debug3: Ignored env ORBIT_SOCKETDIR debug3: Ignored env SSH_AGENT_PID debug3: Ignored env SHELL debug3: Ignored env TERM debug3: Ignored env XDG_SESSION_COOKIE debug3: Ignored env GTK_RC_FILES debug3: Ignored env WINDOWID debug3: Ignored env USER debug3: Ignored env LS_COLORS debug3: Ignored env GNOME_KEYRING_SOCKET debug3: Ignored env SSH_AUTH_SOCK debug3: Ignored env USERNAME debug3: Ignored env SESSION_MANAGER debug3: Ignored env MAIL debug3: Ignored env PATH debug3: Ignored env DESKTOP_SESSION debug3: Ignored env PWD debug3: Ignored env GDM_KEYBOARD_LAYOUT debug3: Ignored env GNOME_KEYRING_PID debug1: Sending env LANG = en_CA.UTF-8 debug2: channel 0: request env confirm 0 debug3: Ignored env GDM_LANG debug3: Ignored env GDMSESSION debug3: Ignored env HISTCONTROL debug3: Ignored env SPEECHD_PORT debug3: Ignored env HOME debug3: Ignored env SHLVL debug3: Ignored env GNOME_DESKTOP_SESSION_ID debug3: Ignored env LOGNAME debug3: Ignored env XDG_DATA_DIRS debug3: Ignored env DBUS_SESSION_BUS_ADDRESS debug3: Ignored env LESSOPEN debug3: Ignored env DISPLAY debug3: Ignored env LESSCLOSE debug3: Ignored env XAUTHORITY debug3: Ignored env COLORTERM debug3: Ignored env _ debug2: channel 0: request shell confirm 1 debug2: fd 3 setting TCP_NODELAY debug2: callback done debug2: channel 0: open confirm rwindow 0 rmax 32768 debug2: channel_input_confirm: type 99 id 0 debug2: PTY allocation request accepted on channel 0 debug2: channel 0: rcvd adjust 2097152 debug2: channel_input_confirm: type 99 id 0 debug2: shell request accepted on channel 0

  Read the article

• Can I use PLink and Pageant with Cygwin's ssh?

  - by Jerph

  I'm now using msysgit because of the GUI tools, which use Putty's Pageant and PLink utilities, but I use Cygwin as a general SSH terminal. I had been using ssh-agent on Cygwin, but that means I have to enter my SSH key passphrases for both SSH key managers. Is it possible to configure all my Unix-port tools (msys, git, cygwin, Ruby Net:SSH, etc.) to use PLink/Pageant instead of ssh-agent? It seems that's the kind of thing PLink was made for, but I can't find documentation on how.

  Read the article

• ssh-agent is broken after running Meerkat - can connect to git in terminal but not in Tower - no keychain access

  - by marblegravy

  My mac running Snow leopard 10.6.8 is having trouble handling it's ssh keys. I could previously access all my git repo's via Tower without an issue. The other day I ran Meerkat to see what it was about and it looks like it has broken the way ssh works. Terminal doesn't seem to have a problem and can still connect to Git, but it can't access the keychain. Tower doesn't seem to be able to access anything. The Tower support crew have been super helpful, but I wanted to float this here and see if anyone has any ideas on how to fix my problem. The only hints I have are: $ which ssh returns: /usr/bin/ssh and echo $SSH_AUTH_SOCK returns: /tmp/ssh-nBhRYVEg8t/agent.199 (This one seems to be wrong as I think it's supposed to point to a Listener, but no idea how to fix it) additional: Keychain first-aid finds no problems. The problem seems to be that ssh-agent is not being run properly... but that's just a guess.

  Read the article

• SSH connection falling down

  - by kappa

  I've set up a connection with autossh that creates some tunnels at system startup, but if I try to connect, after successful login (with RSA key) connection fall down, here a trace: debug1: Authentication succeeded (publickey). debug1: Remote connections from LOCALHOST:5006 forwarded to local address localhost:22 debug1: Remote connections from LOCALHOST:6006 forwarded to local address localhost:80 debug1: channel 0: new [client-session] debug1: Requesting [email protected] debug1: Entering interactive session. debug1: remote forward success for: listen 5006, connect localhost:22 debug1: remote forward success for: listen 6006, connect localhost:80 debug1: All remote forwarding requests processed debug1: Sending environment. debug1: Sending env LANG = it_IT.UTF-8 debug1: Sending env LC_CTYPE = en_US.UTF-8 debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 debug1: client_input_channel_req: channel 0 rtype [email protected] reply 0 debug1: channel 0: free: client-session, nchannels 1 Transferred: sent 2400, received 2312 bytes, in 1.3 seconds Bytes per second: sent 1904.2, received 1834.4 debug1: Exit status 1 What can be the problem? All this stuff is managed by a script already running on another machine (creating reverse tunnels on the same machine but with different ports)

  Read the article

• ssh - "Connection closed by xxx.xxx.xxx.xxx" - using password

  - by Michael B

  I attempted to create an new user account that I wish to use to log in using ssh. I did this (in CentOs): /usr/sbin/adduser -d /home/testaccount -s /bin/bash user passwd testaccount This is the error I receive when trying to log in via ssh: ~/.ssh$ ssh -v [email protected] OpenSSH_5.1p1 Debian-5ubuntu1, OpenSSL 0.9.8g 19 Oct 2007 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Connecting to xxx.xxx.xxx [xxx.xxx.xxx.xxx] port 22. debug1: Connection established. debug1: identity file /home/user/.ssh/identity type -1 debug1: identity file /home/user/.ssh/id_rsa type 1 debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048 debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048 debug1: identity file /home/user/.ssh/id_dsa type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3 debug1: match: OpenSSH_4.3 pat OpenSSH_4* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.1p1 Debian-5ubuntu1 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-cbc hmac-md5 none debug1: kex: client->server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Host 'xxx.xxx.xxx.xxx' is known and matches the RSA host key. debug1: Found key in /home/user/.ssh/known_hosts:8 debug1: ssh_rsa_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 debug1: Authentications that can continue: publickey,gssapi-with-mic,password debug1: Next authentication method: gssapi-with-mic debug1: Unspecified GSS failure. Minor code may provide more information No credentials cache found debug1: Unspecified GSS failure. Minor code may provide more information No credentials cache found debug1: Unspecified GSS failure. Minor code may provide more information debug1: Next authentication method: publickey debug1: Offering public key: /home/user/.ssh/id_rsa debug1: Authentications that can continue: publickey,gssapi-with-mic,password debug1: Trying private key: /home/user/.ssh/identity debug1: Trying private key: /home/user/.ssh/id_dsa debug1: Next authentication method: password testaccount@xxx's password: Connection closed by xxx.xxx.xxx.xxx The "connection closed" message appeared immediately after entering the password (if I enter the wrong password it waits and then prompts for another password) I am able to log in from the same computer using other accounts that had been setup previously. When logged into the remote machine I am able to do 'su testaccount' Thanks for your time.

  Read the article

• ssh client problem: Connection reset by peer

  - by yonix

  I'm having a really annoying problem on my Ubuntu laptop. I noticed it today, after upgrading to Ubuntu 11.04, although I'm not entirely sure this is the cause as I played with my ssh keys a few days ago. The problem is, whenever I try to ssh to ANY host I get the following error: Read from socket failed: Connection reset by peer running with -vvv gives the following output: OpenSSH_5.8p1 Debian-1ubuntu3, OpenSSL 0.9.8o 01 Jun 2010 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug2: ssh_connect: needpriv 0 debug1: Connecting to hostname [10.0.0.2] port 22. debug1: Connection established. debug1: permanently_set_uid: 0/0 debug1: identity file /root/.ssh/id_rsa type -1 debug1: identity file /root/.ssh/id_rsa-cert type -1 debug1: identity file /root/.ssh/id_dsa type -1 debug1: identity file /root/.ssh/id_dsa-cert type -1 debug1: identity file /root/.ssh/id_ecdsa type -1 debug1: identity file /root/.ssh/id_ecdsa-cert type -1 debug1: Remote protocol version 1.99, remote software version OpenSSH_4.2 debug1: match: OpenSSH_4.2 pat OpenSSH_4* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.8p1 Debian-1ubuntu3 debug2: fd 3 setting O_NONBLOCK debug3: load_hostkeys: loading entries for host "hostname" from file "/root/.ssh/known_hosts" debug3: load_hostkeys: loaded 0 keys debug1: SSH2_MSG_KEXINIT sent Read from socket failed: Connection reset by peer My /etc/ssh/ssh_config: Host * SendEnv LANG LC_* HashKnownHosts yes GSSAPIAuthentication no GSSAPIDelegateCredentials no I can connect to my laptop from any other server via ssh, and I can also ssh localhost from my laptop successfully. I can connect to all these other server from other laptops, and I don't see anything in the logs of the other servers regarding my failed attempt. I tried to stop iptables, didn't help. I tried several tricks I could find online with my /etc/ssh/ssh_config, but I was unsuccessful in solving the problem... Any ideas? Edit: This is the log from one of the hosts I try to connect to: May 1 19:15:23 localhost sshd[2845]: debug1: Forked child 2847. May 1 19:15:23 localhost sshd[2845]: debug3: send_rexec_state: entering fd = 8 config len 577 May 1 19:15:23 localhost sshd[2845]: debug3: ssh_msg_send: type 0 May 1 19:15:23 localhost sshd[2845]: debug3: send_rexec_state: done May 1 19:15:23 localhost sshd[2847]: debug1: rexec start in 5 out 5 newsock 5 pipe 7 sock 8 May 1 19:15:23 localhost sshd[2847]: debug1: inetd sockets after dupping: 3, 3 May 1 19:15:23 localhost sshd[2847]: Connection from 10.0.0.7 port 55747 May 1 19:15:23 localhost sshd[2847]: debug1: Client protocol version 2.0; client software version OpenSSH_5.8p1 Debian-1ubuntu3 May 1 19:15:23 localhost sshd[2847]: debug1: match: OpenSSH_5.8p1 Debian-1ubuntu3 pat OpenSSH* May 1 19:15:23 localhost sshd[2847]: debug1: Enabling compatibility mode for protocol 2.0 May 1 19:15:23 localhost sshd[2847]: debug1: Local version string SSH-2.0-OpenSSH_5.3 May 1 19:15:23 localhost sshd[2847]: debug2: fd 3 setting O_NONBLOCK May 1 19:15:23 localhost sshd[2847]: debug2: Network child is on pid 2848 May 1 19:15:23 localhost sshd[2847]: debug3: preauth child monitor started May 1 19:15:23 localhost sshd[2847]: debug3: mm_request_receive entering May 1 19:15:23 localhost sshd[2848]: debug3: privsep user:group 74:74 May 1 19:15:23 localhost sshd[2848]: debug1: permanently_set_uid: 74/74 May 1 19:15:23 localhost sshd[2848]: debug1: list_hostkey_types: ssh-rsa,ssh-dss May 1 19:15:23 localhost sshd[2848]: debug1: SSH2_MSG_KEXINIT sent May 1 19:15:23 localhost sshd[2848]: debug3: Wrote 784 bytes for a total of 805 May 1 19:15:23 localhost sshd[2848]: fatal: Read from socket failed: Connection reset by peer

  Read the article

• VNC connection via SSH proxy machine

  - by pufferfish

  I would like to make a VNC connection from home to a Windows machine at work. The Windows machine is not accessible from the outside, but there is a Linux box that does have port 22 open, so it would seem that this can be done. I suspect it's just a command that "forwards" connections to port 22 on the Linux machine to the Windows machine? Just can't find an example that does exactly this though Thanks in advance!

  Read the article

< Previous Page | 4 5 6 7 8 9 10 11 12 13 14 15  | Next Page >