Tag Info

New answers tagged

1

If you need the public key for whitelisting, you cannot pick it from failed attempt. It is not about sshd or its configuration at all, but the protocol itself, as public key authentication goes this way: Client sends an ID for the key pair. Server compares the ID to the authorized_keys file. Server generates a random number and uses the matching public key ...


0

sshd doesn't actually log the publickeys used in login attempts, successful or otherwise. The closest it gets is to log the fingerprint of the public key at LogLevel VERBOSE. Push the publickey via some other method than failed login attempt. E.g. upload to a cgi/php script that records (either rate controlled appends or overrides ) the key to a file ...


1

You have to launch ssh in such way: ssh -f user@server -p 12345 -L localhost:3306:dbserver.ip:3306 -N Explanation: ssh -f user@myserver -p 12345 - connect to the myserver on the port 12345 -L localhost:3306:dbserver.ip:3306 - all packets destinated to the localhost:3306 will be forwarded to the dbserver.ip:3306 through the myserver. You can use FQDN or ...


0

Your server seems to be called "localhost", which makes the logs a little confusing at first glance. It's also not clear whether your server has IP address 192.168.1.100 or something else. However... The log files show something logging in to your server "localhost" from the server 192.168.1.100 as root. I would suggest that it's not an attack but rather an ...


0

Bring the mountain to mohammed? ssh user@remote "sudo scp -r user@local:/path/to/files /opt/bin" It seems like that is a whole lot of privilege with nary a password to be seen, which would make me nervous.


2

The biggest problem with the protocol described in that tutorial is that it doesn't specify how you "download the private key to the client machine" in a secure manner (i.e., that prevents eavesdropping). If you don't already have a secure channel, the key will presumably be transferred in clear over the Internet (HTTP, FTP, email, etc). You can use HTTPS, ...


15

Congratulations, you've found an Internet tutorial with bad advice. The problem with using a single keypair for multiple computers occurs when any one of the computers is compromised. Then you have no choice but to revoke the keypair everywhere and rekey every single computer which was using that keypair. You should always use unique keypairs per machine ...


1

Here is a problem: Enter file in which to save the key (/home/karl/.ssh/id_rsa): openshiftKey You didn't accept the default, and gave your key a specific filename. If you had accepted the default, then ssh would simply look in that default location anytime you make a remote connection to anywhere, and try to use that key. In order to use a key other ...


0

You may also use the following syntax: ssh-agent sh -c 'ssh-add /foo/cert.pem && echo Do some stuff here.'


0

You may also use the following syntax: ssh-agent sh -c 'ssh-add && echo Do some stuff here.'


4

StrictModes checks the home directory permissions not just the .ssh directory. As the man pages say: This is normally desirable because novices sometimes accidentally leave their directory or files world-writable. Authentication refused: bad ownership or modes for directory /home/myUser. Says it has a problem with the home directory permissions.


1

Turns out, this was due to having changed the port number of ssh in /etc/services Debug steps in case others have similar problems: First I ran: GIT_CURL_VERBOSE=1 GIT_TRACE=1 git ls-remote git@github.com:<github_user>/<app_name> In the debug, the following line was hanging: trace: run_command: 'ssh' 'git@github.com' 'git-upload-pack ...


3

The first and best solution is to simply not allow SSH logins to the root account. As you've found for yourself, this makes it very hard to track who did what. People who should have access to a server should use their own accounts, and then use sudo to perform tasks requiring root access. This is the current best practice for SSH access. You might also ...


3

There is no way to both retain auditing capabilities and letting users become root. Instead, grant sudo access to the commands your users need, and log everything. From the sudoers(5) man page: sudoers also supports logging a command's input and output streams. I/O logging is not on by default but can be enabled using the log_input and log_output ...


1

No. sshd cannot authenticate users that do not exist according to the system it is running on. The user must exist, though they need not be defined locally.


6

There's no command-line option in OpenSSH to pass a host key fingerprint. Though you can use a temporary file (with the same format as known_hosts) and make ssh use that using -o UserKnownHostsFile: ssh -o "UserKnownHostsFile my_temp_known_host" host.example.com See ssh (for -o) and sshconfig (for UserKnownHostsFile) man pages. You may also consider ...


0

The AuthorizedKeysCommand description in the sshd_config should produce on standard output zero or more lines of authorized_keys output This means you can generate a command= option complete w/ command line arguments (or any other valid authorized_key option). For example, the dynamically generated line could be something like: ...


1

Were you able to generate that size of key on the intended target system? You may be running into a limit to what is supported. Rather current Centos system of mine supports a 16k maximum which seems sufficient for massive keys. You should see the maximum if you try to go above it with ssh-keygen as shown below. [nathan@omni ~]# ssh-keygen -t rsa -b 32768 ...


1

If you mean a non-local user, yes, it is perfectly possible, freeIPA, for example, can store users' public keys in its LDAP backend: ipa user-mod user –sshpubkey='ssh-rsa AAAA…' and uses: AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys AuthorizedKeysCommandRunAs nobody in /etc/ssh/sshd_config effectively delegating the validation of authorized ...


2

Your command (ssh -v example.cloudapp.net : 22) says to connect to example.cloudapp.net and then execute the command : 22 and exit. From what I can see it succeeds in doing this. I would guess that you tried to specify the port number(?) but that is not how you do it. First of all, port 22 is default for ssh, so there's no need to specify it but if you ...


1

Yes. (padding padding padding padding)


3

Put it in your $HOME/.ssh/config file. For example: Host bad.example.com Port 2222 Host * Port 22


4

You can setup key based authentication for the local/trusted hosts and everywhere else go w/ two factor google-authenticator. I use google-authenticator module as well for all ssh logins from external hosts. However, for trusted, local hosts, I setup key based authentication which bypasses google authentication so it is much easier to login... not to ...


0

looks like you are having an issue with ssh key on the server/client... have a look at http://askubuntu.com/questions/205179/ssh-problem-read-from-socket-failed-connection-reset-by-peer (slightly different error but most of the socket errors are similar troubleshooting wise.. ) and also clear known host file when you re try connecting from laptop/desktop ...


3

Connections which stall and eventually recover is almost certainly caused by packet drops. It should be very clear from a packet capture, when there has been a packet drop. If a packet was send by one end of the connection and not received by the other end, then it must have been dropped by the intermediate network. It is possible that packets are corrupted ...


1

You didn't post your proftpd.conf file, which would be really helpful. However, it sounds like you haven't explicitly set TimeoutIdle in your proftpd.conf file. Add this to your file: # Timeout after 3600 seconds (60 minutes) TimeoutIdle 3600 If you already have something like that, then post your conf file so we can better help you. Obviously, just ...


1

ssh -v -i .ssh/namenode.pub root@datanode1 When you specify an ssh key on the command line, it should be the private key file, not the public file. So you should reference .ssh/namenode here, not .ssh/namenode.pub. It looks like you added the private key to ssh-add, but there's no indication in the ssh debug trace that it communicated with the ssh agent ...


2

It means someone is connecting to ssh repeatedly. Look at your syslog (probably /var/log/auth.log). If ssh is open to the internet, this is quite common. Ensure you have good passwords set and root is not allowed to log in. You can use fail2ban and a myriad of other tools to block them automatically. You can also use iptables to limit access to networks you ...


0

When logging in using ssh the ~/.bashrc is not source - but the ~/.bash_profile is - so if you set the LD_LIBRARY_PATH in ~/.bashrc you need to have something like this in your ~/.bash_profile: # Get the aliases and functions if [ -f ~/.bashrc ]; then . ~/.bashrc fi And also, in your ~/.bashrc you may have: # If not running interactively, don't ...


1

You need to enable port 22 inbound in the ec2 security group you setup for that instance.


0

Same exact problem here to access a dedicated server at the online.net datacenter. Theres no problem after a reboot, no need to change MTU, ssh connection works for 1-3 weeks, then appears this exact same bug , blocking on KEXINIT, no more possible to connect the ssh server. It could be some kind of sshd bug, but its necessarily triggered by some nework ...


0

You really need to check on the server for what sshd is logging but with the info provided my initial guess would be that the server is rejecting the keys. As to why - see the server logs it initially I'd guess incorrect permissions.


0

I had the same problem and the easiest solution I came through was to remove openssh and install it again. yum remove openssh and then: yum install openssh openssh-server openssh-clients then you can start sshd service: service sshd start


3

Have you checked the contents of '/etc/ssh/sshd_config'? Your command does not rewrite this file, it appends to it. And the first line in this file (by default) is 'UsePAM yes'. And this option will be used, as it comes earlier... If you do not have a valid ssh key, the root will be asked for password in this case, because you have 'UsePAM yes' ...


-2

You have to disable PasswordAuthentication and enable PermitRootLogin like this: PasswordAuthentication no PermitRootLogin yes


0

Try /sbin/restorecon -r /root/.ssh A possible problem with selling permissions.


0

There was some kind of problem reading the SSH config from the non-default SSH config file (config_prod). I put everything in the default 'config' file and dropped the -F flag and all is "well".


-1

THis still occured daily. but solved it by setting a cron reinstall yum install -y openssh-server never had the issue anymore.


1

You need to make the ssh server keys only readable by root again: chmod 600 /etc/ssh/ssh_host_*_key may do the job


2

You will only get "failed login attempt" messages on accounts that you're actually logging into. Since SSH scanners typically try some common names of people, and also known system accounts like 'root', what that message tells me is that you're logging in as root directly over SSH. You should not do this. The first thing to do is create a regular user ...


0

I can't add a comment so ... what is the OP actually trying to do, stop a user from accessing clients with remote capabilities? Turn off all internet access? Are you realy wanting to prevent incoming access to ports used for remote access [sudo ufw enable does that as the default is to drop all incoming requests]?? Removing the execute and/or read bits on ...


0

Make his home directory /foo-home. This will redirect him to what is effectively /mnt/foo-jail/foo-home. To address the authorized_keys issue you mentioned in comments, add this under Match user foo: AuthorizedKeysFile /mnt/foo-jail/%h/.ssh/authorized_keys


1

With syslog-ng, you can reformat a log message, and even do more complex things, but it depends on what SSHD actually logs about the connections. Can you post some sample logs about the SFTP downloads to see what information is available? Robert


0

Ok, that was now really hard work. ;-) I could found the solution here https://github.com/tmatilai/vagrant-proxyconf/issues/109. Modifying the Vagrant no proxy variable to: config.proxy.no_proxy = "localhost,127.0.0.1,/var/run/docker.sock solves the problem.


-3

is quite a simple fix and can be completed in a few minutes via the standard cPanel /scripts Login to your server as root via SSH Run: /scripts/updatenow Run: /scripts/fixndc This will fix your problems some of the time, but if it does not, do the following steps: Login to your server as root via SSH Run: vi /etc/rndc.conf (or vi /etc/namedb/rndc.conf ...


1

You'll need to create a public key from this private key, using putty-keygen or something similar. Put the public key on the server into the home directory of the user you want to connect as and add key to the ~/.ssh/authorized_keys file. Then change the permissions appropriately: cd ~ chmod 700 .ssh chmod 600 .ssh/authorized_keys


1

I think you should try with: ssh user@111.11.111.111 tar -c --bzip2 -f - /home/user/example.com/public/ > Backups/File_Backups/example/example_public_`date +%d%b%Y`.tar.bz2


0

If you are using Git command line for Windows you can do as following: Open cmd.exe and execute setx HOME c:\PATH_TO_PRIVATE_KEY Create new folder .ssh (if not exist) inside c:\PATH_TO_PRIVATE_KEY and copy your id_rsa file (your private key) into it. Done, now you can use git commanline normally


2

There's a difference in establishing a TCP/IP connection, completing the SSH protocol negotiation and completing the SSH authentication with success or failure. The Internet is full of bots doing the first and failing at the second step, especially with Ssh obfuscation, which is what your logs show. That snippet doesn't show successful logins since it ...


1

This is because ssh uses ephemeral ports.The logged port is port that the client is using to connect, not the port the server accepted the connection on. Your netstat -tp output will have a line similar too: tcp 0 0 server.example.com:51722 client.example.com:49344 ESTABLISHED 15825/sshd



Top 50 recent answers are included